Archivo de la categoría: EIDAS

TPP, AISP, PISP, ASPSP – Términos de PSD2 y eIdAS


La entrada en vigor de la Segunda Directiva de Pagos (PSD2) recogida en la legislación española en el Real Decreto-ley 19/2018, de 23 de noviembre, de servicios de pago y otras medidas urgentes en materia financiera, permite el desarrollo de nuevos servicios financieros en Europa e impulsa un nuevo marco de competencia.

Aparecen nuevos términos, que conviene conocer en inglés y en español para entender mejor el nuevo contexto competitivo marcado por el “Open Banking”.

Término Descripción
AIS Account Information Services. Servicios de Información de Cuentas. Servicios accesibles mediante API (Application Program Interface) para los TPP (Third Party Provider) Prestadores Financieros  en los que obtener información de los usuarios de servicios de pago.
AISP Account Information Service Provider. Proveedor de servicios de información sobre cuenta.  Prestador Financiero que obtiene información de varias entidades en nombre de un usuario de servicios de pago y se las presenta de forma consolidada.
API Application Programming Interface. Interfaz de Programación de Aplicación. Una API proporciona a una entidad una forma sistemática de obtener información o iniciar acciones en otra entidad. Mediante parámetros y opciones pueden programarse diferentes servicios a terceros.
ASPSP Account Servicing Payment Service Provider.  Proveedor de servicios de pago gestor de cuenta. Una entidad financiera en la que un usuario de servicios de pago tiene cuentas a cuya información un Prestador Financiero puede acceder en su nombre o en la puede iniciar una transferencia.
Autenticacion El proceso de confirmar la identidad de un Prestador Financiero o de un usuario de servicios de pago. Existen pautas como SCA – Strong Customer Authentication (Autenticación Reforzada de Cliente) o mecanismos como los certificados eIdAS para garantizar la correcta identificación.
Autorización El proceso de confirmar la  funcionalidad permitida según las credenciales de un Prestador Financiero o de un usuario de servicios de pago. Inicialmente la funcionalidad se limita a acceder a información de cuentas o iniciar transferencias, según el tipo de prestador (AISP o PISP).
Consentimiento El acuerdo por el que el usuario de servicios de pago otorga al Prestador la posibilidad de acceder a su información bancaria o iniciar transferencias.
eIdAS Reglamento UE 910/2014 que regula, entre otros aspectos los requisitos de expedición de certificados cualificados QWAC para sitios web y certificados cualificados para sello electrónico de los diferentes Prestadores. Los certificados los expiden  QTSPs – Qualified Trust Service providers, Prestadores cualificados de servicios electrónicos de confianza
NCA National Competent Authority. Autoridad Nacional Competente.  Organismo regulador o supervisor de entidades financieras que autoriza a un Prestador Financiero a operar en el nuevo marco de servicios financieros PSD2 cuando cumpla ciertos requisitos. En España, es el Banco de España.
PIS Payment Initiation Services. Servicios de iniciación del pagos. Servicios de transferencia bancaria gestionados por un Prestador Financiero en nombre de un usuario de servicios de pago a través de una API ofrecida por su Proveedor de servicios de pago gestor de cuenta.
PIIS Payment Issuer Instrument Service. Servicio asociado a medio de pago para solicitar por API la autorización de pago con tarjeta indicando el importe (comprueba la validez de la tarjeta y la disponibilidad del importe).
PISP Payment Initiation Service Provider. Proveedor de servicios de iniciación de pago. Prestador Financiero de servicios de transferencia bancaria gestionados en nombre de un usuario de servicios de pago a través de una API ofrecida por su Proveedor de servicios de pago gestor de cuenta. Puede requerirse por parte del ASPSP la confirmación del usuario.
PSU Payment Service User. Usuario de servicios de pago.
QTSP Qualified Trust Service Provider. Prestadores cualificados de servicios electrónicos de confianza. Expiden certificados cualificados QWAC para sitios web y certificados cualificados para sello electrónico de los diferentes Prestadores Financieros. Los certificados permiten identificar a los Prestadores Financieros cuando usan las APIs de otras entidades en entornos de Producción.
SCA Strong Customer Authentication. Autenticación Reforzada de Cliente. Proceso de confirmar la identidad del usuario. Normalmente se usan dos o más factores de autenticación:

  • “Algo que sabes”
  • “Algo que tienes”
  • “Algo que te caracteriza”
Sandbox Experimentos con gaseosa. Zona de pruebas.

El término en inglés Sandbox se refiere a una zona de juegos para niños en la que no estropean nada ni se hacen daño.  Se amplía a usos profesionales en los que se prueban desarrollos con funcionalidades similares a las del entorno real antes del paso a producción.

TPP Third Party Provider. Prestador Financiero. AISP o PISP.  Actúa en nombre de un usuario de servicios de pago accediendo a su información bancaria en otra entidad o iniciando una transferencia. Requiere una licencia por parte de una NCA y puede operar en otros países en virtud del concepto de “pasaporte” haciendo uso de certificados eIdAS.

Prestador-Financiero

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.

 

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 “.

Norma del CCN para firma en la nube


CCN-CertificacionLos dispositivos cualificados de creación de firma son necesarios para producir firmas electrónicas y sellos electrónicos cualificados en el contexto del Reglamento 910/2014 (EIDAS).

Dada la lentitud del proceso de publicación en el seno del CEN (Comité Europeo de Normalización) de las normas de evaluación de conformidad de dispositivos cualificados de creación de firma que promovía el Reglamento EIDAS, en su artículo 30, en 2016 el Centro Criptológico Nacional (CCN) impulsó la publicación de una norma propia a lo que le autorizaba el propio artículo 30 en su apartado 3-b.

En efecto, el artículo 30 en su apartado 1 indica:

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.

Y en su apartado 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

(…)

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.

En abril de 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.

Sin embargo, esta norma solo hacía mención al marco de evaluación Common Criteria (ISO/IEC 15408 — Information technology — Security techniques — Evaluation criteria for IT security (Tecnología de la información — Técnicas de seguridad — Criterios de evaluación para la seguridad de la TI), Partes 1 a 3 y a la norma de perfiles de protección de dispositivos seguros de creación de firma EN 419 211 — Protection profiles for secure signature creation device (Perfiles de protección para los dispositivos seguros de creación de firma, Partes 1 a 6), que pasaba de puntillas sobre los requisitos de firma en la nube (limitado a la parte  EN 419 211-5).

En base a la Directiva 1999/93/CE se había publicado en julio del año 2003 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 que permitía contar con dispositivos seguros de creación de firma mientras evolucionaba el marco de normas técnicas de evaluacón de conformidad.

Dado el interés de algunas entidades españolas en certificar dispositivos cualificados de creación de firma (necesarios, por ejemplo, para finalizar el proyecto de DNI en la nube) el Centro Criptológico Nacional publicó en enero de 2017 la norma IT-009 -Remote Qualified Electronic Signature Creation Device Evaluation Methodology.

Esta norma se publicó al amparo del apartado 3-b del artículo 30 de EIDAS:

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

(…)

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).

El documento recoge lo esencial de las normas técnicas en estado borrador en ese momento y posicionó a España en la punta de lanza de la evaluación de conformidad. Debe agradecerse al CCN esta labor proactiva que redunda en la competitividad de las empresas españolas del sector de la seguridad.

Por parte de TCAB (Trust Conformity Assessment Body) fué un privilegio el que pudiéramos colaborar en los trabajos preparatorios previos a la publicación de la norma.

Digital por diseño


Va llegando el momento de abandonar el término “transformación digital” que transmite la idea de que hay que cambiar los procesos de las organizaciones, conforme avanza la digitalización de la sociedad y la adopción masiva de las tecnologías de la información.

Con el estado actual de la tecnología y de la legislación, no tiene sentido diseñar procesos de información, contratación o mero trámite que no estén diseñados desde el principio pensando en el valor probatorio de los registros digitales administrados con ayuda de la criptografía.

En todo caso, cualquier concesión a procedimientos o actuaciones arcaicos debe ser en atención a la experiencia de usuario.

Uno de los aspectos claves del nuevo paradigma es la gestión de la identidad digital de las personas con las que se relacionan las entidades que debería tener en cuenta la posibilidad de acceso de personas de diversa procedencia y medios de identificación.

Las “piezas de lego” que facilitan la gestión digital por diseño de los procedimientos preservando la seguridad jurídica son componentes como las firmas electrónicas de persona, los sellos electrónicos de empresa, los sistemas de conservación digital de documentos electrónicos (incluso con códigos seguros de verificación) y evidencias electrónicas, los sellos de tiempo electrónicos, los sistemas de gestión de información de representación (de otras personas o de empresas) los sistemas que permiten comprobar la validez de las firmas y de los sellos, los que permiten gestionar mecanismos de identificación y de firmas y sellos “en la nube”, los que permiten realizar la digitalización certificada de documentos, los que permiten la identificación remota co y los que permiten acreditar las notificaciones electrónicas.

En la actualidad. el Reglamento (UE) Nº 910/2014, de 23 de julio, relativo a la identificación electrónica y los servicios de confianza para las transacciones electrónicas en el mercado interior (eIDAS), ofrece una buena base para construir sistemas digitales con valor legal admisibles en todos los países miembros, sea cual sea el país de origen, de entre los europeos.

Un aspecto clave en la digitalización por diseño es que la experiencia de usuario debe ser una de las principales prioridades en el diseño de los procesos, para evitar repetir errores de usabilidad  que en el pasado no contribuyeron a poner en valor tecnologías como el DNI electrónico, que se expide desde 2006.

El despliegue de sistemas digitales de gestión debería preservar principios esenciales como el “soporte duradero” o la “simetría probatoria” (igualdad de armas) para que los usuarios de las plataformas cuenten con la misma posición respecto a la prueba digital que los promotores de las plataformas.

El conocimiento técnico y legal de estos principios de despliegue digital ayudará a las entidades a diseñar sistemas digitales eficientes, sencillos y con valor probatorio por lo que es útil contar con especialistas a los que consultar.

Los sistemas de gestión de identidad disponibles ya contemplan la interoperabilidad entre países con “nodos eIDAS” como el español que se instancia a través del sistema “Cl@ve“.