Archivo de la categoría: #eIdaS

Amadeus cytric Travel & Expense – Digitalización Certificada


cytric_LogoAmadeus cytric Travel & Expense es una plataforma global para gestión de viajes y gastos orientado a dar servicio a grandes empresas que facilita a los empleados de estas entidades, que viajan por necesidades de negocio, la gestión de forma rápida y sencilla de sus gastos de viaje.

La plataforma permite la reserva online flexible para vuelos, trenes, habitaciones de hotel, alquiler de coches, taxis y traslados, incluida una gama completa de familias de tarifas aéreas y servicios complementarios.

Integra las transacciones realizadas con tarjeta de crédito en el proceso de capturar y revisar los tickets, facturas simplificadas y facturas completas, con una experiencia de usuario sencilla y rápida, que permite presentar hojas de gastos sin demora y agilizar su cobro teniendo en cuenta los recibos y las dietas, según el marco fiscal aplicable al viajero, así como las reglas de negocio propias de su empresa.

Con la aplicación de móvil de cytric, los empleados de una empresa que tienen que viajar, pueden buscar y reservar viajes y alojamientos, revisar sus itinerarios, presentar sus gastos online, acceder a contactos y servicios locales, obtener recibos de gastos, y aprobar o rechazar solicitudes de viajes y de reembolso de gastos.

Optimiza el flujo de trabajo de la agencia de viajes de negocios seleccionada con reglas de validación, registros de auditoría, notificaciones, recordatorios e hilos de discusión automatizados que ayudan a todos los roles involucrados en el proceso de viaje, incluidos viajeros, autorizadores, auditores y contables.

Amadeus ha confiado en EADTrust para realizar la auditoría de Digitalización Certificada de su solución cytric Travel & Expense – Certified Digitization Engine y la ha presentado a la Agencia Tributaria que resolverá sobre la concesión de la Homologación a la plataforma. Un equipo multidisciplinar coordinado con profesionales situados en varios países ha dado forma a un motor de digitalización integrado en la plataforma que permite cumplir con todos los requisitos de la Norma EHA/962/2007 de 10 de abril y la Resolución de 24 de octubre de 2007 de la Agencia Estatal de Administración Tributaria española.

 

John Cock-pigeon Identity – Blockchain


Las denominaciones de los sistemas y de las tecnologías deberían ser significativas para los usuarios.

Traigo el tema a colación de la denominación “Self Sovereign Identity” que suele traducirse como “identidad autosoberana” trasladando a un contexto jurídico continental principios de gestión de identidad que nos son ajenos y responden a necesidades de países que adoptan el derecho de la “Common Law”, tan diferente del nuestro. Es un tipo de propuesta, normalmente basada en infraestructuras de tipo Blockchain, que encuentra eco en nuestra sociedad.

En España, acreditar la identidad a distancia es sumamente sencillo, con el DNI electrónico, si bien, hay que reconocer que algo falla cuando el uso actual de esta posibilidad es tan escaso.

En países en los que no existe el DNI se opta por emitir un “carné de conducir de no conductores” que no deja de ser un documento de identidad expedido por el estado.

Pero en muchos contextos, uno acredita su identidad con lo que puede: contratos en los que se indica el nombre y apellidos y la otra parte los admite, facturas en las que figuran datos de identificación y de dirección de suministro (agua, gas, electricidad, teléfono fijo)…

En el fondo, no hay un buen sistema de gestión de identidad y se recurre a empresas como Experian y Equifax (o Dun & Bradstreet  en el caso de empresas) que recopilan datos de identidad y de comportamiento de pagos para refrendar la identidad alegada.

Que en esos contexto se propongan sistemas de tipo SSI (“Self Sovereign Identity”) o similares (caso de Sovrin o uPort) es una consecuencia lógica de la carencia que tratan de resolver.

Sin embargo, en nuestro contexto, la gestión de la identidad no tiene nada que ver con la soberanía (mucho menos a nivel individual) por lo que sistemas de base tan primitiva la podríamos llamar “Identidad Juan Palomo” (“yo me lo guiso, yo me lo como) y todo el mundo entendería la base de la propuesta: acreditamos un dato que nos pidan con algún “papel” que nos haya expedido un tercero tras cumplir ciertos requisitos (el carné del videoclub, una factura, un título universitario,…).

No es que en España no se use la “Identidad Juan Palomo”, lo que sucede es que la demostración más sencilla y eficaz de la identidad a secas la proporciona el DNI:

El DNI tiene suficiente valor, por sí solo, para acreditar la identidad y los datos personales de su titular que en él se consignen, así como la nacionalidad española del mismo. (RD 1553/2005)

Los servicios de Equifax y Experian siguen siendo útiles en la prevención del fraude (como ya expliqué en los artículos de “Documentos Perdidos/Sustraídos” y “Documentos Robados/Extraviados“) pero no se consideran una primera referencia para la gestión de identidad.

De modo que si nos llega a parecer que la denominación “John Cock-pigeon Identity” no es la mejor traducción del concepto para un angloparlante, quizá debamos cuestionar si la denominación “Identidad autosoberana” significa lo mismo en español.

Certificados de prueba #eIdAS para #PSD2


Hace ya algún tiempo traté sobre los certificados que se podrían usar en el contexto de PSD2, en el artículo “Directiva PSD2 y certificados #eIdAS de Proveedores de Servicios de Pago

Todavía antes (en 2017) traté temas técnicos (algunos controvertidos) de PSD2 en el artículo “Segunda directiva de servicios de pago (PSD2) y Regulatory Technical Standards

PSD2-PI-AI-Card

Ahora ya hay más información y sabemos como se codificarán las Autoridades Nacionales Competentes en los certificados de los prestadores delos diferentes servicios definidos en PSD2:

i) Servicios de cuenta (PSP_AS) que proporcionan las entidades financieras actuales;
ii) Servicios de iniciación de pagos (PSP_PI) que proporcionarán nuevas entidades accediendo a las cuentas que sus clientes tienen en los proveedores de servicios de cuenta y ordenando transferencias en su nombre;
iii) Servicios de información de cuentas (PSP_AI) que proporcionarán nuevas entidades accediendo a las cuentas que sus clientes tienen en los proveedores de servicios de cuenta y recogiendo las transacciones de varias entidades para presentarlas al cliente de formas más interesantes o útiles;
iv) Servicios de expedición de instrumentos de pago basados en tarjetas (PSP_IC), para emisión de servicios equivalentes a tarjetas virtuales o adquirencia de transacciones de pago de tarjetas.

La lista de entidades es

Code Country Authority Title
AT-FMA Austria Austria Financial Market Authority
BE-NBB Belgium National Bank of Belgium
BG-BNB Bulgaria Bulgarian National Bank
HR-CNB Croatia Croatian National Bank
CY-CBC Cyprus Central Bank of Cyprus
CZ-CNB Czech Czech National Bank
DK-DFSA Denmark Danish Financial Supervisory Authority
EE-FI Estonia Estonia Financial Supervisory Authority
FI-FINFSA Finland Finnish Financial Supervisory Authority
FR-ACPR France Prudential Supervisory and Resolution Authority
DE-BAFIN Germany Federal Financial Supervisory Authority
GR-BOG Greece Bank of Greece
HU-CBH Hungary Central Bank of Hungary
IS-FME Iceland Financial Supervisory Authority
IE-CBI Ireland Central Bank of Ireland
IT-BI Italy Bank of Italy
LI-FMA Liechtenstein Financial Market Authority Liechtenstein
LV-FCMC Latvia Financial and Capital Markets Commission
LT-BL Lithuania Bank of Lithuania
LU-CSSF Luxembourg Commission for the Supervision of Financial Sector
NO-FSA Norway The Financial Supervisory Authority of Norway
MT-MFSA Malta Malta Financial Services Authority
NL-DNB Netherlands The Netherlands Bank
PL-PFSA Poland Polish Financial Supervision Authority
PT-BP Portugal Bank of Portugal
RO-NBR Romania National Bank of Romania
SK-NBS Slovakia National Bank of Slovakia
SI-BS Slovenia Bank of Slovenia
ES-BE Spain Bank of Spain
SE-FINA Sweden Swedish Financial Supervision Authority
GB-FCA United Kingdom Financial Conduct Authority

Las URLS de las NCA (National Competent Authorities) Autoridades Naciones Competentes se ven en la siguiente lista:

Country Competent authority
Austria Financial Market Authority
Belgium National Bank of Belgium
Bulgaria Bulgarian National Bank
Croatia Croatian National Bank for credit institutions and Croatian Financial Services Supervisory Agency for investment firms
Cyprus Central Bank of Cyprus
Czech Republic Czech National Bank
Denmark Finanstilsynet
ECB (SSM) European Central Bank (SSM)
Estonia Financial Supervision Authority
Finland Finanssivalvonta (Fin-FSA)
France Autorité de contrôle prudentiel et de Resolution
Germany BaFin and Bundesbank
Greece Bank of Greece
Hungary Central Bank of Hungary
Iceland Financial Supervisory Authority
Ireland Central Bank of Ireland
Italy Banca d’Italia
Latvia Financial and Capital Market Commission
Liechtenstein Financial Services Authority
Lithuania Bank of Lithuania
Luxembourg Commission de Surveillance du Secteur Financier
Malta Malta Financial Services Authority
Netherlands De Nederlandsche Bank
Poland Polish Financial Supervision Authority
Portugal Banco de Portugal
Romania National Bank of Romania
Slovakia National Bank of Slovakia
Slovenia Bank of Slovenia
Spain Banco de España
Sweden Finansinspektionen
UK Prudential Regulation Authority and Financial Conduct Authority

Con la novedad de que ya se pueden introducir guiones en el campo organizationIdentifier que mencioné en el artículo “Resuelto uno de los frenos a los certificados cualificados de PSD2” ya se pueden emitir certificados cualificados extended validation para las diferentes entidades que operan en el despliegue de PSD2.

Algunos Prestadores de Servicios de Certificación ya se están preparando para emitirlos (inicialmente, certificados de prueba) y en TCAB ya estamos listos para auditarlos. Llámenos al  91 388 0789

Resuelto uno de los frenos a los certificados cualificados de PSD2


EIDAS-CAB-forumEl CAB Forum ha aprobado una modificación del documento “Extended Validation Guidelines” para permitir incluir guiones en el campo rganizationIdentifier (OID 2.5.4.97) de los certificados EV, con lo que los certificados expedidos en el contexto de la norma ETSI TS 119 495 ya no serán incompatibles con las comprobaciones que realizan los navegadores. De esta forma se podrán expedir certificados QWAC para entidades financieras y otras entidades que operan en aplicación de la Directiva (UE) 2015/2366 llamada Segunda Directiva de Pagos (PSD2).

La propuesta SC17 se ha aprobado con 23 votos favorables de entidades emisoras de certificados y 6 de las entidades desarrolladoras de navegadores (comprobadores de certificados).

Votos a favor:

  • Emisores:  Actalis, Buypass, Camerfirma, Certigna (DHIMYOTIS), Certum (Asseco), Chunghwa Telecom, Comsign, D-TRUST, DarkMatter, DigiCert, eMudhra, Entrust Datacard, Firmaprofesional, GDCA, GlobalSign, GoDaddy,  SHECA, SSC, SecureTrust (anteriormente Trustwave), TurkTrust.
  • Comprobadores: Apple, Cisco, Google, Microsoft, Mozilla, 360

1 Abstención (Emisores): TrustCor

Con este resultado, se permite la inclusión de información adicional en los certificados EV para cumplir con ciertas regulaciones de la Unión Europea.

La motivación argumentada que dio lugar a la solicitud que se ha votado fue:

  • El Reglamento de la Unión Europea Nº 910/2014 (eIDAS)  define ciertos requisitos reglamentarios para los certificados con un nivel de calidad acordado denominado “Cualificado”. Este reglamento especifica en el Anexo IV los requisitos específicos para “Certificados cualificados para la autenticación de sitios web”, incluida la declaración de que el certificado contendrá: “para personas jurídicas: al menos el nombre de la persona jurídica a la que se expida el certificado y, cuando proceda, el número de registro, tal como se recojan en los registros oficiales;
  • Se entiende que este requisito se relaciona con los atributos validados para la identificación del sujeto del certificado y, por lo tanto, se ajusta mejor al nombre distinguido del sujeto (subject’s distinguished name).
  • En línea con el marco regulatorio, ETSI ha definido una estructura general para llevar “números de registro” en la norma TS 119 412-1 (en la actualidad EN 319 412-1). Ver cláusula 5.1. 4. En ella se utiliza el identificador de organización (organizationIdentifier) de la norma  X.520 dentro del nombre distinguido del  sujeto el propósito de servir como “identificación de una organización diferente del nombre de la organización”. Esto se utiliza para los requisitos de ETSI para llevar los números de registro para certificados, cualificados o de otro tipo.
  • Se considera que este uso de organizationIdentifier es compatible con el propósito principal de los certificados de EV como se indica en la sección 2.1.1 de las Directrices de EV como “otra información desambiguadora”.
  • Un reciente Reglamento delegado de la UE 2018/389 sobre comunicaciones seguras para servicios de pago establece en el artículo 34.2 que para los Certificados de sitio web cualificados (QWAC), el número de registro requerido en eIDAS “será el número de autorización del proveedor de servicios de pago (…) o equivalente [referencia hecha a regulaciones anteriores relacionadas con entidades financieras]”.
  • ETSI ha especificado los requisitos de la norma TS 119 495 para incluir los números de registro relacionados con PSD2 en la estructura general para los números de registro definidos en la citada norma TS 119 412-1 en su cláusula 5.1 .4
  • ETSI se ha esforzado por garantizar y siempre ha intentado que los requisitos relacionados con los certificados de sitios web en el nivel Calificado estén en línea con las pautas de Extended Validation de CA / B Forum.
  • Esta propuesta solo incluye algunos de los Esquemas de registro utilizados en la norma ETSI TS 119 412-1, que tienen reglas de validación claras (NTR, IVA, PSD) que brindan una seguridad razonable de acuerdo con las “EV Guidelines”. Se propone que los IPR (intellectual property rights) para la semántica de este esquema se cedan al CA / B Forum, lo que le permitirá extender aún más el uso del Identificador de la organización (organizationIdentifier) para incluir otros Esquemas de registro (por ejemplo, LEI, Legal Entity Identifier) y las reglas de validación correspondientes, a discreción del CA / B Forum.  Además, cualquier cambio futuro realizado por ETSI a la norma ETSI TS 119 412-1 ya no tendrá impacto adicional en CA / B Forum.
  • Al tomar conciencia de que la interpretación del CA / B Forum de los “Requisitos de EV” en la sección 9.2.8 “Otros Atributos” no estaba en línea con la forma de entenderlos por los expertos de ETSI, este organismo desearía armonizar su interpretación con la de CA / B Forum para reflejar en los certificados diferentes formas de establecer números de registro para PSD2 y otros esquemas de identificación alfanumérica de entidades.

Por otro lado, las preocupaciones específicas del CA / B Forum eran:

  • Los requisitos con respecto a los atributos que se han de incluir en el DN (Distinguished Name) del sujeto deben recogerse de forma explícita en el apartado 9.2.
  • Las organizaciones pueden desear identificar las unidades organizativas dentro de su organización. No está claro si esto está permitido actualmente en las Directrices de EV (ambigüedad similar a la de la sección 9.2.8).
  • Se han argumentado objeciones al uso específico de ETSI del campo Distinguished Name.
  • Los procedimientos para la validación del atributo deben estar claramente establecidos.
  • Puede haber otros usos del campo OrganizationIdentifier  en varias PKI, sin embargo, no se considera un problema. dado que la semántica única que se está especificando para cada identificador, las aplicaciones deben ser capaces de comprender los diferentes usos del campo organizationIdentifier  por diferentes emisores y usuarios. Hay muchas “PKI” diferentes que pueden usar todos los atributos de X.500 de manera diferente y con una validación diferente o sin ninguna validación. Según parece, el WebPKI no ha usado anteriormente este atributo de subjectDN antes para los Certificados de confianza pública (Publicly-Trusted Certificates). Por lo tanto, no hay “conflicto” al usar este atributo en las Directrices EV para Certificados SSL / TLS, y tal vez más adelante para Certificados de Firma de Código EV.
  • Este uso de OrganisationIdentifier debe ser extensible para permitir el uso de otros números de registro asignados por diferentes esquemas de registro. Algunos miembros de CAB Forum han expresado interés en incluir números de registro que no sean para identificar el tipo de sociedad dentro de Certificados EV. Esto está previsto en la propuesta actual.
  • Algunos miembros del CA / B Forum tienen interés en llevar incluir las identificaciones LEI dentro de los certificados del CA / B Forum, pero hasta ahora el esquema de registro LEI no se considera lo suficientemente extendido como para ser reconocido como un esquema de numeración de registro para ser aceptado por el CA / B Forum. Por lo tanto, esta propuesta solo introduce un conjunto limitado de esquemas de registro (a saber, NTR, IVA, PSD) que tienen reglas de validación razonablemente sólidas.
  • Algunos miembros del CA / B Forum han indicado la posible necesidad de múltiples identificadores en el campo “nombre del sujeto”. Sin embargo, esto no se puede lograr utilizando el campo definido en la norma X.520 organizationIdentifier que definió este atributo como “SINGLE VALUE”.

Los cambios aprobados, que se reflejarán el documento “EV Guidelines” son:

  • Agregar a la sección 4 las siguientes definiciones:
    Entidad legal: una organización privada, entidad gubernamental, entidad comercial o entidad no comercial.
    Referencia de registro: un identificador único asignado a una entidad legal (persona jurídica).
    Esquema de registro: un esquema para asignar una referencia de registro que cumple con los requisitos identificados en el Apéndice H. “
  • Cambiar el título de la Sección 9.2 para indicar”Campos de Nombre Distinguido del Sujeto” (Subject Distinguished Name Fields).
  • Eliminar la Sección 9.2.2 y renumerar las secciones 9.2.3 a 9.2.8 como 9.2.2 a 9.2.7.
  • Insertar una nueva sección 9.2.8:
    “9.2.8. Campo identificador de organización del sujeto
    ** Campo de certificado **: organizationIdentifier (OID: 2.5.4.97)
    ** Requerido / Opcional **: Opcional
    ** Contenido **: Si está presente, este campo DEBE contener una referencia de registro para una entidad legal asignada de acuerdo con el Esquema de registro identificado.
    El organizationIdentifier DEBE estar codificado como PrintableString o UTF8String (ver RFC 5280).
    El Esquema de Registro DEBE identificarse utilizando la siguiente estructura en el orden presentado:
    * Identificador de esquema de registro de 3 caracteres;
    * Se utilizará el código de país ISO 3166 de 2 caracteres para la nación en la que opera el Esquema de Registro, o si el esquema se opera globalmente, se utilizará el código ISO 3166 “XG”
    * Para el identificador del Esquema de Registro NTR, si es requerido bajo la Sección 9.2.4, un identificador ISO 3166-2 de dos caracteres para la subdivisión (estado o provincia) de la nación en la que opera el Esquema de Registro, precedido por el signo más “+” ( 0x2B (ASCII), U + 002B (UTF-8));
    * un guión (signo menos) “-” (0x2D (ASCII), U + 002D (UTF-8));
    * Referencia de registro asignada de acuerdo con el Esquema de Registro identificado.Nota: las Referencias de Registro PUEDEN contener guiones, pero los Esquemas de Registro, los códigos de país ISO 3166 y los identificadores ISO 3166-2 no PUEDEN contenerlos. Por lo tanto, si aparece más de un guión en la estructura, el guión más a la izquierda es un separador, y los guiones restantes forman parte de la Referencia de Registro.Como en la sección 9.2.4, la información de ubicación especificada DEBE coincidir con el alcance del registro al que se hace referencia.Ejemplos:
    * NTRGB-12345678 (esquema NTR, Gran Bretaña, cuyo identificador único a nivel de país es 12345678)
    * NTRUS + CA-12345678 (Esquema NTR, Estados Unidos – California, cuyo identificador único a nivel estatal es 12345678)
    * VATDE-123456789 (Esquema de IVA o CIF, Alemania, cuyo Identificador único a nivel de país es 12345678)
    * PSDBE-NBB-1234.567.890 (Esquema de PSD2, Bélgica, con identificador de la NCA (National Competent Authority) por sus siglas NBB, y con identificador único del sujeto asignado por la NCA formado por la secuencia 1234.567.890)

    Los esquemas de registro enumerados en el Apéndice H se reconocen actualmente como válidos bajo estas pautas (“Guidelines”).

    La CA DEBE:
    1. confirmar que la organización representada por la Referencia de Registro es la misma que la organización nombrada en el campo de organización como se especifica en la Sección 9.2.1 dentro del contexto de la jurisdicción del sujeto según se especifica en la Sección 9.2.4;
    2. Verificar además que la Referencia de registro coincida con otra información verificada de acuerdo con la sección 11;
    3. Tomar las medidas adecuadas para desambiguar entre diferentes organizaciones como se describe en el Apéndice H para cada Esquema de Registro;
    4. Aplicar las reglas de validación relevantes al Esquema de Registro como se especifica en el Apéndice H. “

  • Insertar nueva sección 9.8 (renumerar las siguientes secciones según sea necesario):
    9.8. Extensiones de Certificado
    Las extensiones enumeradas en la Sección 9.8 se recomiendan para la máxima interoperabilidad entre los certificados y los navegadores / aplicaciones, pero no son obligatorias en las CA, excepto cuando se indica como “Requerido”. Las CA pueden usar otras extensiones que no están enumeradas en esta Sección 9.8, pero se les recomienda que propongan su inclusión en esta sección de vez en cuando para ayudar a aumentar la estandarización de la extensión en toda la industria.Si una CA incluye una extensión en un certificado que tiene un campo de Certificado que se menciona en esta Sección 9.8, la CA debe seguir el formato especificado en esa subsección. Sin embargo, ninguna extensión o formato de extensión será obligatorio en una CA a menos que se indique específicamente como “Requerido” en la subsección que describe la extensión.9.8.1. Extensión del nombre alternativo del sujeto (Subject Alternative Name Extension)
    ** Campo del certificado: ** _subjectAltName: dNSName_
    ** Requerido / Opcional: ** Requerido
    ** Contenido: ** Esta extensión DEBE contener uno o más nombres de dominio de host que sean propiedad o estén controlados por el sujeto y que estén asociados con el servidor del sujeto. Dicho servidor PUEDE ser propiedad y operado por el Sujeto u otra entidad (por ejemplo, un servicio de alojamiento). Los certificados comodín no están permitidos para los certificados EV.9.8.2. Campo de identificador de organización del foro de CA / navegador
    ** Nombre de la extensión **: _cabfOrganizationIdentifier_ (OID: 2.23.140.3.1)
    ** OID detallado **: {joint-iso-itu-t (2) international-Organizations (23) ca-browser-forum (140) extensiones de certificado (3) cabf-organization-identifier (1)}
    ** Requerido / Opcional **: Opcional (pero ver más abajo)
    ** Contenido **: Si el asunto: organizationIdentifier está presente, este campo DEBE estar presente.

    A partir del 31 de enero de 2020, si está presente el campo sujeto: organizaciónIdentificador, este campo DEBE estar presente.
    Si está presente, este campo DEBE contener una Referencia de Registro para una entidad legal asignada de acuerdo con el esquema de registro identificado.

    El esquema de registro DEBE estar codificado como se describe en la siguiente gramática ASN.1:

    id-CABFOrganizationIdentifier OBJECT IDENTIFIER ::= 
    { joint-iso-itu-t(2) international-organizations(23) 
    ca-browser-forum(140) certificate-extensions(3) 
    cabf-organization-identifier(1) }
    
    ext-CABFOrganizationIdentifier EXTENSION ::= 
    { SYNTAX CABFOrganizationIdentifier IDENTIFIED BY 
    id-CABFOrganizationIdentifier }
    
    CABFOrganizationIdentifier ::= SEQUENCE {
    
    registrationSchemeIdentifier   PrintableString (SIZE(3)),
    
    registrationCountry            PrintableString (SIZE(2)),
    
    registrationStateOrProvince    [0] IMPLICIT PrintableString OPTIONAL (SIZE(0..128)),
    
    registrationReference          UTF8String
    
    }
    

    donde están los subcampos y tienen los mismos significados y restricciones descritos en la Sección 9.2.8. La CA DEBE validar el contenido utilizando los requisitos de la Sección 9.2.8 “.

  • Añadir nuevo Apéndice H – Esquemas de registro
    “Los siguientes esquemas de registro se reconocen actualmente como válidos según estas pautas:** NTR **: La información incluida en este campo será la misma que se guardó en el campo Número de registro del sujeto como se especifica en 9.2.5 y el código de país utilizado en el identificador del esquema de registro coincidirá con el de la jurisdicción del sujeto según se especifica en la Sección 9.2.4.
    Cuando la Jurisdicción de constitución de la entidad o el Campo de Registro en 9.2.4 incluya más que el código del país, la información de localidad adicional se incluirá como se especifica en las secciones 9.2.8 y / o 9.8.1.** IVA **: Referencia asignada por las autoridades fiscales nacionales a una entidad jurídica. Esta información se validará utilizando la información provista por la autoridad fiscal nacional contra la organización identificada por el campo Nombre de la organización del sujeto (ver 9.2.1) y el campo del número de registro del sujeto (ver 9.2.5) dentro del contexto de la jurisdicción del sujeto según se especifica en la Sección 9.2.4.

    ** PSD **: Número de autorización especificado en ETSI TS 119 495, cláusula 4.4, asignado a un proveedor de servicios de pago y que contiene la información especificada en ETSI TS 119 495 cláusula 5.2.1. Esta información SE DEBE obtener directamente del registro de la autoridad nacional competente para servicios de pago o de una fuente de información aprobada por una agencia gubernamental, organismo regulador o legislación para este propósito. Esta información DEBE validarse comparándola directa o indirectamente (por ejemplo, haciendo coincidir un número de registro único global) con la organización identificada por el campo Nombre de la organización del sujeto (ver 9.2.1) y el Campo del número de registro del sujeto (ver 9.2.5). ) dentro del contexto de la jurisdicción del sujeto según se especifica en la Sección 9.2.4. La dirección indicada de la organización combinada con el nombre de la organización NO SERÁ la única información utilizada para desambiguar la organización “.

Nuevas normas de ETSI para firmas digitales en la nube


El comité técnico de ETSI sobre Infraestructura de firma electrónica (TC ESI, technical committee on Electronic Signature Infrastructure) acaba de publicar un conjunto de tres Especificaciones técnicas para firmas digitales basadas en la nube que admiten dispositivos móviles: ETSI TS 119 431-1, ETSI TS 119 431-2 y ETSI TS 119 432.

Este nuevo conjunto de estándares promueve la creación de firmas digitales en la nube, lo que facilita la adopción de las tecnologías de firma electrónica al evitar la necesidad de software especializado por parte de los usuarios y la de contar con dispositivos seguros de creación de firma, tales como lectores de tarjeta chip.

El acrónimo TW4S (Trustworthy System Supporting Server Signing) se usa con frecuencia para identificar los entornos de firma electrónica en la nube.

El firmante confía en un servicio de confianza ofrecido por terceros especialistas para administrar su clave secreta de firma electrónica y para firmar digitalmente bajo su control aquellos documentos electrónicos que considere.

Para garantizar que es confiable el entorno de creación de firmas basado en la nube y que la clave privada de firma se usa bajo el control del firmante, el prestador del servicio de firma digital remota debe aplicar procedimientos seguros de gestión y utilizar sistemas y productos confiables, incluyendo canales seguros de comunicación electrónica.

Según Nick Pope, Vicepresidente del comité ESI de ETSI, “este es un gran paso en la seguridad de los despliegues de firmas digitales que tiene en cuenta la tendencia de adopción de servicios basados ​​en la nube y la generalización de los dispositivos móviles. Estas normas permiten una nueva forma de implementar los Servicios de confianza que simplifica enormemente su uso y proporciona un conjunto de herramientas importante para contrarrestar el creciente fraude de Internet dirigido a empresas y organismos”.

Las normas ETSI TS 119 431 partes 1 y 2 definen requisitos de política y seguridad que los organismos de evaluación de la conformidad (Conformity Assessment Bodies) pueden utilizar para certificar que un prestador de servicios de confianza sigue las mejores prácticas para la operación de dichos servicios de creación de firmas basados ​​en la nube, en particular en el contexto del Reglamento eIDAS (UE) 910/2014. Este trabajo de ETSI complementa las publicaciones del Comité Europeo de Normalización, CEN EN 419241-1: 2018 (requisitos generales para sistemas confiables que dan soporte a la firma electrónica en servidor) y EN 419241-2: 2019 (perfil de protección para dispositivos cualificados de creación de firma electrónica (QSCD) para la firma en servidor), que proporcionan los requisitos básicos de la firma electrónica en la nube.

Cloud-signature

La norma ETSI TS 119 432 especifica el protocolo que permite a una aplicación cliente solicitar la creación de una firma digital a un servidor. Esta especificación establece un protocolo para la comunicación segura entre los diferentes componentes necesarios para crear una firma digital segura en la nube, en consonancia con los estándares de seguridad establecidos en el Reglamento eIDAS. Se especifican dos tipos de conexión para implementar este protocolo: XML, que se basa en la especificación OASIS DSS-v2.0, y JSON, que se basa en la especificación del Cloud Signature Consortium (CSC). ETSI colaboró ​​con ambs organismos de normalización, OASIS y CSC para elaborar estas especificaciones de protocolo.

TCAB, Trust Conformity Assessment Body ya está considerando esta nuevas normas para las evaluaciones de conformidad de firma en la nube de sus clientes. Estas normas no están contempladas todavía por ENAC para su uso en la evaluación de servicios cualificados. Para más información, llame a 91 388 0789 

Lightweight Online Certificate Status Protocol (OCSP) en entornos de alto volumen de certificados


OCSPEl Protocolo de consulta en linea del estado de certificados (Online Certificate Status Protocol – OCSP) permite determinar el estado de vigencia o revocación de los certificados digitales sobre los que se consulta, como mecanismo alternativo al uso de listas de revocación de certificados (Certificate Revocation List – CRL).

Desde su definición en 1999, se ha desplegado en múltiples entornos y ha demostrado su utilidad hasta el punto de que se ha convertido en el mecanismo preferido de verificación de vigencia de certificados establecido en el Reglamento EIDAS.

En efecto, el  Art 24 indica:

(…)

3.   Cuando los prestadores cualificados de servicios de confianza que expidan certificados cualificados decidan revocar un certificado, registrarán su revocación en su base de datos de certificados y publicarán el estado de revocación del certificado oportunamente y, en todo caso, en un plazo de 24 horas después de la recepción de la solicitud. La revocación será efectiva inmediatamente después de su publicación.

4. Con respecto a lo dispuesto en el apartado 3, los prestadores cualificados de servicios de confianza que expidan certificados cualificados proporcionarán a cualquier parte usuaria información sobre el estado de validez o revocación de los certificados cualificados expedidos por ellos. Esta información deberá estar disponible al menos por cada certificado en cualquier momento y con posterioridad al período de validez del certificado en una forma automatizada que sea fiable, gratuita y eficiente.

Un servidor OCSP debe responder en “tiempo real”, generando una respuesta de información de vigencia por cada consulta relativa a un certificado.

A medida que el uso de tecnologías PKI continúa creciendo y cubre nuevos requerimientos, la necesidad de comprobar la vigencia de los certificados debe adaptarse a nuevos escenarios.

Al pensar en despliegues de dispositivos ubicuos en contextos de IoT (Internet de las cosas) con menores capacidades de proceso y quizá menor ancho de banda  se requiere un uso cuidadoso de OCSP para minimizar el uso de ancho de banda y la complejidad de procesamiento del lado del cliente. Si a eso se añade que pueden existir millones o cientos de millones de certificados expedidos para otros tantos dispositivos, el potencial consumo de ancho de banda destinado a OCSP cuando las entidades que confían en los certificados consultan su validez hacer recomendable contar con mecanismos optimizados. De ahí la conveniencia de contar con una versión ligera de OCSP que con el tiempo pueda ser adoptada por los diferentes intervinientes en estos contextos de despliegues masivos de certificados.

Estas consideraciones han dado lugar a la publicación del estándar RFC 5019, que simplifica el protocolo OCSP manteniendo la compatibilidad con versiones anteriores.

Confusión en torno a los dispositivos cualificados de creación de firma y sello electrónicos


He detectado un error difundido entre especialistas en firma electrónica y certificación en relación con los requisitos que existen en el marco del EIDAS (Reglamento UE 91/2014) para que un dispositivo de creación de sello electrónico o de firma electrónica tenga la consideración de cualificado.

El error probablemente procede de una respuesta a preguntas frecuentes publicada en la página web de la Secretaría de Estado de Avance Digital, Organismo Supervisor del sector de los servicios de confianza y de la certificación.

La pregunta es:

¿Qué es un dispositivo cualificado de creación de firma / de sello electrónico?

Y la respuesta publicada por la SEAD dice:

Un dispositivo de creación de firmas electrónicas que cumple los requisitos enumerados en el anexo II del Reglamento (UE) 910/2014. Asimismo, un dispositivo cualificado de creación de sello electrónico es aquel que cumple, mutatis mutandis, los requisitos indicados en el anexo II del Reglamento (UE) 910/2014.

De acuerdo con el artículo 30 del Reglamento (UE) 910/2014, la certificación es una condición sine qua non para la consideración de un dispositivo de creación de firma o sello electrónico como cualificado. La citada certificación obligatoria, que atestiguará el cumplimiento de los requisitos establecidos en el anexo II del citado Reglamento, podrá ser únicamente llevada a cabo por los organismos europeos designados al efecto de acuerdo con su artículo 30.2, en concreto en España, el Centro Criptológico Nacional.

La lista de dispositivos cualificados que han sido notificados a la Comisión Europea por parte de los Estados miembros en virtud del artículo 31 del Reglamento (UE) 910/2014 contiene, en consecuencia, todos aquellos dispositivos que han sido certificados, por lo que cualquier otro dispositivo que no figure en la citada lista no tiene la consideración de dispositivo cualificado.

Puede encontrar información actualizada sobre la lista de organismos europeos de certificación y la lista de dispositivos cualificados de creación de firma y sello en la página de la Comisión Europea.

Sin embargo, si leemos detalladamente el Reglamento EIDAS, lo que dice es bien distinto:

Artículo 29

Requisitos de los dispositivos cualificados de creación de firmas electrónicas

1.   Los dispositivos cualificados de creación de firmas electrónicas cumplirán los requisitos establecidos en el anexo II.

2.   La Comisión podrá, mediante actos de ejecución, establecer números de referencia de normas relativas a los dispositivos cualificados de creación de firmas electrónicas. Se presumirá el cumplimiento de los requisitos establecidos en el anexo II cuando un dispositivo cualificado de creación de firmas electrónicas se ajuste a dichas normas. Estos actos de ejecución se adoptarán con arreglo al procedimiento de examen contemplado en el artículo 48, apartado 2.

Artículo 30

Certificación de los dispositivos cualificados de creación de firmas electrónicas

1.   La conformidad de los dispositivos cualificados de creación de firmas electrónicas con los requisitos que figuran en el anexo II será certificada por los organismos públicos o privados adecuados designados por los Estados miembros.

2.   Los Estados miembros notificarán a la Comisión los nombres y direcciones de los organismos públicos o privados a que se refiere el apartado 1. La Comisión pondrá la información a disposición de los Estados miembros.

3.   La certificación contemplada en el apartado 1 se basará en los elementos siguientes:

a) un proceso de evaluación de la seguridad llevado a cabo de conformidad con las normas para la evaluación de la seguridad de los productos de tecnología de la información incluidos en la lista que se establecerá de conformidad con el párrafo segundo, o

b) un proceso distinto del proceso contemplado en la letra a), con tal de que ese proceso haga uso de niveles de seguridad equivalentes y que los organismos públicos o privados a los que se refiere el apartado 1 notifiquen ese proceso a la Comisión. Podrá recurrirse a ese proceso únicamente a falta de las normas a que se refiere la letra a) o cuando esté en curso el proceso de evaluación de la seguridad a que se refiere la letra a).

La Comisión establecerá, por medio de actos de ejecución, la lista de las normas para la evaluación de la seguridad de los productos de tecnología de la información a que se refiere la letra a). Dichos actos de ejecución se adoptarán con arreglo al procedimiento de examen contemplado en el artículo 48, apartado 2.

4.   La Comisión estará facultada para adoptar actos delegados, de conformidad con el artículo 47, en lo que respecta al establecimiento de criterios específicos que deben satisfacer los organismos designados a que se refiere el apartado 1 del presente artículo.

Como puede apreciarse, lo que dice el Reglamento (art 29) es que se presumirá el cumplimiento de los requisitos establecidos en el anexo II cuando un dispositivo cualificado de creación de firmas electrónicas se ajuste a dichas norma, no que sea una condición “sine qua non”. Es decir, puede haber otras formas de demostrar los requisitos establecidos en el anexo II. De  hecho, los requisitos del Anexo II son esencialmente los mismos que se incluían en el Anexo III de la Directiva 1999/93:

ANEXO III – Directiva 1999/93

Requisitos de los dispositivos seguros de creación de firma electrónica

1. Los dispositivos seguros de creación de firma garantizarán como mínimo, por medios técnicos y de procedimiento adecuados, que:

a) los datos utilizados para la generación de firma sólo pueden producirse una vez en la práctica y se garantiza razonablemente su secreto;

b) existe la seguridad razonable de que los datos utilizados para la generación de firma no pueden ser hallados por deducción y la firma está protegida contra la falsificación mediante la tecnología existente en la actualidad;

c) los datos utilizados para la generación de firma pueden ser protegidos de forma fiable por el firmante legítimo contra su utilización por otros.

2. Los dispositivos seguros de creación de firma no alterarán los datos que deben firmarse ni impedirán que dichos datos se muestren al firmante antes del proceso de firma.

REQUISITOS DE LOS DISPOSITIVOS CUALIFICADOS DE CREACIÓN DE FIRMA ELECTRÓNICA (Reglamento EIDAS)

1.

Los dispositivos cualificados de creación de firma electrónica garantizarán como mínimo, por medios técnicos y de procedimiento adecuados, que:

a) esté garantizada razonablemente la confidencialidad de los datos de creación de firma electrónica utilizados para la creación de firmas electrónicas;

b) los datos de creación de firma electrónica utilizados para la creación de firma electrónica solo puedan aparecer una vez en la práctica;

c) exista la seguridad razonable de que los datos de creación de firma electrónica utilizados para la creación de firma electrónica no pueden ser hallados por deducción y de que la firma está protegida con seguridad contra la falsificación mediante la tecnología disponible en el momento;

d) los datos de creación de la firma electrónica utilizados para la creación de firma electrónica puedan ser protegidos por el firmante legítimo de forma fiable frente a su utilización por otros.

2.

Los dispositivos cualificados de creación de firmas electrónicas no alterarán los datos que deben firmarse ni impedirán que dichos datos se muestren al firmante antes de firmar.

3.

La generación o la gestión de los datos de creación de la firma electrónica en nombre del firmante solo podrán correr a cargo de un prestador cualificado de servicios de confianza.

4.

Sin perjuicio de la letra d) del punto 1, los prestadores cualificados de servicios de confianza que gestionen los datos de creación de firma electrónica en nombre del firmante podrán duplicar los datos de creación de firma únicamente con objeto de efectuar una copia de seguridad de los citados datos siempre que se cumplan los siguientes requisitos:

a) la seguridad de los conjuntos de datos duplicados es del mismo nivel que para los conjuntos de datos originales;

b) el número de conjuntos de datos duplicados no supera el mínimo necesario para garantizar la continuidad del servicio.

La similitud de requisitos entre el Anexo III de la Directiva y el Anexo II del Reglamento se ha reflejado en el artículo 51.1 del EIDAS:

1.   Los dispositivos seguros de creación de firma cuya conformidad se haya determinado con arreglo a lo dispuesto en el artículo 3, apartado 4, de la Directiva 1999/93/CE se considerarán dispositivos cualificados de creación de firma electrónica con arreglo al presente Reglamento.

En el contexto de la Directiva, inicialmente los dispositivos considerados dispositivos seguros de creación de firma electrónica eran los certificados en el ámbito del NIST. Inicialmente los FIPS-140-1 y posteriormente los FIPS 140-2 desde el 25 de mayo de 2001.

Hasta el año 2001 no existió una norma equivalente en el contexto europeo. En esa fecha se crearon en el CEN (Comité Europeo de Normalización) los borradores de las normas CWA 14167, CWA 14168 y CWA 14169 que finalmente se aprobaron en su versión final en el 2004. En el año 2003 se publicó la Decisión 2003/511/CE:de la Comisión, de 14 de julio de 2003, relativa a la publicación de los números de referencia de las normas que gozan de reconocimiento general para productos de firma electrónica, de conformidad con lo dispuesto en la Directiva 1999/93/CE del Parlamento Europeo y del Consejo

Estos son los dispositivos a los que hace referencia el artículo 3, apartado 4, de la Directiva 1999/93/CE

Y en todo el  tiempo desde la publicación de la Directiva (1999) hasta la publicación de esta Decisión el cumplimiento del Anexo III se suponía que se llevaba a cabo por dispositivos certificados  FIPS-140-1 y s FIPS 140-2.

Tras la entrada en vigor del Reglamento EIDAS (publicado en 2014) pasó un tiempo sin que se aprobaran los nuevos estándares, por lo que siguieron siendo válidos los dispositivos seguros de creación de firma de la Directiva 1999/93.

En aplicación del apartado 3-b del artículo 30 cabía definir un proceso distinto del proceso contemplado en la letra a), con tal de que ese proceso hiciera uso de niveles de seguridad equivalentes y que los organismos públicos o privados a los que se refiere el apartado 1 notificaran ese proceso a la Comisión. Solo podía recurrirse a ese proceso  a falta de las normas a que se refiere la letra a) o cuando esté en curso el proceso de evaluación de la seguridad a que se refiere la letra a).

España definió un proceso propio al amparo del apartado 3-b que se recogió en la “List of alternative processes notified to the Commission in accordance with Article 30.3(b) and 39.2 of the eIDAS Regulation (EU) No 910/2014

El documento de metodología definido por le Centro Criptológico Nacional “IT-009 – Remote Qualified Electronic Signature Creation Device Evaluation Methodology” se publicó en Enero de 2017, cuando ya empezaban a estar disponibles los borradores de las normas de evaluación de QSCD (Qualified Signature Cretion Device)

En 2016 se publicó la DECISIÓN DE EJECUCIÓN (UE) 2016/650 DE LA COMISIÓN de 25 de abril de 2016 por la que se fijan las normas para la evaluación de la seguridad de los dispositivos cualificados de creación de firmas y sellos con arreglo al artículo 30, apartado 3, y al artículo 39, apartado 2, del Reglamento (UE) n.o 910/2014 del Parlamento Europeo y del Consejo, relativo a la identificación electrónica y los servicios de confianza para las transacciones electrónicas en el mercado interior

Una vez publicados los estándares quedaban sin efecto las normas transitorias.

Por resumir:

Hay varias circunstancias por las que un dispositivo tenga la consideración de cualificado:

Porque cumplía con el Anexo III de la Directiva:

  • FIPS-140-1 y FIPS-140-2
  • Common Criteria EAL4 (y EAL4+, o superior) en base a la norma CWA 14169, Según la Decisión 2003/511/CE:de la Comisión,

Porque cumple con el anexo II del Reglamento:

  • Common Criteria EAL4 (y EAL4+, o superior) en base a la norma EN 419211 (partes 1 a 6) Según la DECISIÓN DE EJECUCIÓN (UE) 2016/650 
  • Normas transitorias en aplicación del art. 30 2 b del EIDAS (como la IT-009 del CCN)
  • Normas transitorias en aplicación del art. 51.1 del EIDAS: Common Criteria EAL4 (y EAL4+, o superior) en base a la norma CWA 14169, Según la Decisión 2003/511/CE:de la Comisión,