Archivo de la categoría: CA/B Forum

¿Qué QTSP es más activo en Criptoagilidad preparando el Criptocalipsis?

2 respuestas

La criptoagilidad (o agilidad criptográfica) es la capacidad de un sistema, software o infraestructura tecnológica para adaptarse rápidamente a nuevos algoritmos criptográficos o cambiar los existentes sin requerir modificaciones significativas en su arquitectura. Esto implica poder actualizar, reemplazar o ajustar los métodos de cifrado, firmas digitales o protocolos de seguridad de manera eficiente para responder a amenazas emergentes, como el avance en la computación cuántica, vulnerabilidades descubiertas o cambios en estándares regulatorios.

EADTrust es el Prestador de Servicios de Confianza Cualificados más activo de España en lo relativo a la adecuación frente a los retos de la computación cuántica analizando y adoptando las soluciones emergentes de la criptogrfía postcuántica. A nivel europeo, también Digicert, Entrust y Sectigo han mostrado actividad en estos aspectos

Yo mismo he ido impartiendo conferencias a lo largo de los años sobre la necesaria preparación frente a a computación cuántica y algunas están disponibles en Youtube. Y publiqué un artículo en este blog en 2018: La urgente adopción de la criptografía postcuántica. También otro sobre recientes avances como el chip Majorana.

La criptoagilidad y la disponibilidad de infraestructuras con diferentes algoritmos permiten anticiparse al criptocalipsis. El criptocalipsis (o apocalipsis criptográfico) es un término que describe un escenario hipotético en el que los algoritmos criptográficos actuales, como RSA, ECC (curvas elípticas) o AES, se vuelven obsoletos o vulnerables debido a avances tecnológicos, particularmente la llegada de la computación cuántica

EADTrust fue la primera entidad de certificación que preparó jerarquías de certificación de tamaños de clave mejores que RSA de 2048 bits, y en la actualidad es la única con jerarquías de PKI para certificados cualificados de tamaños de clave RSA de 8196 bits, especialmente orientada a proyectos de alta seguridad, con resistencia a la computación cuántica.

También EADTrust fue la primera entidad de certificación que preparó jerarquías de certificación basadas en criptografía no-RSA. Cuenta con dos jerarquías de certificación basada en Criptografía de Curvas elípticas, ECC-255 y ECC-384.

La disponibilidad de jerarquías ECC por parte de EADTRUST fue esencial para que España pudiera desplegar los pasaportes COVID ágilmente, ya que EADTrust fue el Prestador que pudo emitir en tiempo récord los certificados adecuados basados en ECC-255 para todos los organismos sanitarios españoles con las especificaciones de la OMS y de la Unión Europea.

En estos momentos hemos anunciado un importante curso presencial de 2 dias: Formación sobre Computación Cuántica y Criptografía Postcuántica. Se enmarca entre los Servicios de EADTrust de preparación de infraestructuras para afrontar los retos de la Computación Cuántica en relación con la Criptografía y la Preservación de documentos.

Además estamos haciendo seguimiento de los nuevos estándares de criptografía postcuántica como el FIPS-206 Falcon al que nos hemos referido recientemente en este blog y el prometedor HQC (Hamming Quasi-Cyclic).

El NIST seleccionó HQC (procedente de la ronda 4) como algoritmo adicional para estandarizar como KEM de respaldo a ML-KEM. El NIST anunció que creará un borrador (IPD) para HQC y lo publicará para comentarios — el cronograma indicado apunta a publicar el borrador aproximadamente en 1 año desde su anuncio y una versión final alrededor de 2027.

Ya tenemos servicios disponible para clientes que se desean valorar el impacto de su preparación (criptoagilidad) para los grandes cambios que se avecinan:

  • Adaptación de servidores web (en la conexión segura «https://») para incluir TLS1.3 (RFC 8446) y la configuración necesaria para que la gestión de claves del cifrado de las comunicaciones se realice con el algoritmo ML-KEM/Kyber que ya soportan servidores y navegadores web como primera aproximación de mecanismos híbridos. Ver IETF draft-ietf-tls-kem-tls-13
  • Adaptación de servidores web para soportar el protocolo ACME (Automatic Certificate Management Environment) basado en el RFC 8555, como paso hacia una infraestructura automatizada, segura y criptoágil. Además de poder configurar a EADTrust como Autoridad de Certificación generadora de certificados para TSL con ACME, en el Certbot se pueden configurar otras CAs. Aunque contamos con varios mecanismos de verificación de dominio damos preferencia a las variantes con información actualizada en el DNS. La duración máxima de los certificados TLS públicos se reducirá progresivamente a 47 días, según lo aprobado por el CA/Browser Forum en abril de 2025 mediante el Ballot SC-081v3, propuesto por Apple y respaldado por los principales navegadores (Apple, Google, Mozilla y Microsoft). Esta es otra buena razón para incorporar a automatización a la renovación de certificados de servidor web

Los nuevos certificados cualificados de sitio web 1-QWAC y 2-QWAC

1 respuesta

Continúa la publicación de estándares de ETSI para apoyar el desarrollo de EIDAS y EIDAS2. Algunos de ellos forman parte de los actos de ejecución de EIDAS2.

Uno de los aspectos desarrollados es el que tiene que ver con los certificados cualificados de autenticación de sitios web (en inglés QWAC Qualified Website Authentication Certificates), con dos enfoque técnicos diferentes (1-QWAC y 2-QWAC).

Con la publicación del Reglamento 2024/1183 la redacción de los artículos 45 y 45 bis quedó así:

Artículo 45 – Requisitos aplicables a los certificados cualificados de autenticación de sitios web

  1. Los certificados cualificados de autenticación de sitios web cumplirán los requisitos establecidos en el anexo IV. La evaluación del cumplimiento de dichos requisitos se llevará a cabo de conformidad con las normas, especificaciones y procedimientos a que se refiere el apartado 2 del presente artículo.

1 bis. Los proveedores de navegadores web reconocerán los certificados cualificados de autenticación de sitios web expedidos de conformidad con el apartado 1 del presente artículo. Los proveedores de navegadores web garantizarán que los datos de identificación de la persona declarados en el certificado y los atributos declarados adicionales se muestren al usuario de un modo fácil de consultar. Los proveedores de navegadores web garantizarán la compatibilidad e interoperabilidad con los certificados cualificados de autenticación de sitios web a que se refiere el apartado 1 del presente artículo, con la excepción de las microempresas y pequeñas empresas según se definen en el artículo 2 del anexo de la Recomendación 2003/361/CE durante sus primeros cinco años de actividad como prestadores de servicios de navegación web.

1 ter. Los certificados cualificados de autenticación de sitios web no estarán sometidos a ningún requisito obligatorio que no sean los requisitos establecidos en el apartado 1.

  1. A más tardar el 21 de mayo de 2025, la Comisión establecerá, mediante actos de ejecución, una lista de normas de referencia y, en su caso, las especificaciones y los procedimientos aplicables a los certificados cualificados de autenticación de sitios web a que se refiere el apartado 1 del presente artículo. Dichos actos de ejecución se adoptarán con arreglo al procedimiento de examen contemplado en el artículo 48, apartado 2.».

Artículo 45 bis – Medidas cautelares en materia de ciberseguridad

  1. Los proveedores de navegadores web no adoptarán ninguna medida contraria a sus obligaciones establecidas en el artículo 45, en particular los requisitos de reconocer los certificados cualificados de autenticación de sitios web y de mostrar los datos de identificación de la persona proporcionados de un modo que sea fácil de consultar.
  2. No obstante lo dispuesto en el apartado 1 y solo en caso de preocupaciones justificadas relacionadas con violaciones de la seguridad o la pérdida de integridad de un certificado o conjunto de certificados identificados, los proveedores de navegadores web podrán adoptar medidas cautelares en relación con dicho certificado o conjunto de certificados.
  3. Cuando se adopten medidas, los proveedores de navegadores web notificarán, en virtud del apartado 2, sus preocupaciones por escrito, sin demora indebida, junto con una descripción de las medidas adoptadas para mitigarlas, a la Comisión, al organismo de supervisión competente, a la entidad a la que se haya expedido el certificado y al prestador cualificado de servicios de confianza que haya expedido dicho certificado o conjunto de certificados. Tras la recepción de dicha notificación, el organismo de supervisión competente expedirá un acuse de recibo al proveedor del navegador web en cuestión.
  4. El organismo de supervisión competente investigará las cuestiones planteadas en la notificación, de conformidad con el artículo 46 ter, apartado 4, letra k). Cuando el resultado de la investigación no implique la retirada de la cualificación del certificado, el organismo de supervisión informará de ello al proveedor del navegador web y solicitará que ese proveedor ponga fin a las medidas cautelares a que se refiere el apartado 2 del presente artículo.».

Para aterrizar este articulado, se ha publicado recientemente la norma técnica de ETSI ETSI TS 119 411-5 V2.1.1 que orienta a los navegadores en la implementación de los certificados QWAC.

Y hace pocos días el acto de ejecución correspondiente, que todavía está en forma de borrador con plazo de comentarios hasta el 2 de octubre de 2025.

En resumen, existen dos opciones para la integración de certificados web cualificados en los servidores, denominadas «one quack and two quacks» (haciendo broma con la onomatopeya de un graznido y dos graznidos).

Corresponden a las etiquetas 1-QWAC y 2-QWAC.

1-QWAC consiste en añadir información a los certificados TLS existentes. Con este enfoque, los QWAC son certificados TLS (Publicly Trusted Certificates) que cumplen las normas actuales, como los Requisitos básicos  (Baseline Requirements) de CA/Browser Forum. También tendrían que cumplir cualquier requisito adicional impuesto por los programas de aceptación de certificados raíz de los navegadores web.

2-QWAC es una solución más alambicada. Equivale a mantener separados los ecosistemas TLS de CABForum y los QWAC del Reglamento EIDAS. Para ello se expiden dos certificados simultáneamente: uno TLS (PTC) estándar (que puede ser emitido por una CA diferente, incluida en los programas de Root-CA de los navegadores) y otro QWAC (derivado de la norma TS 119 411-2) con un enlace para conectarlos protegido criptográficamente. La información sobre el enlace debe enviarse a través de una cabecera HTTP Link, pero el enlace en sí es un archivo JSON firmado con la clave privada para la que se emite el certificado QWAC. Un enlace puede respaldar varios certificados TLS, lo que es una ventaja para quienes deseen admitir varios certificados al mismo tiempo.

El enfoque 2-QWAC supone poner deberes a los navegadores, ya que tienen que gestionar una nueva cabecera HTTP, añadir código para obtener el enlace e implementar una nueva firma (utilizando JSON Advanced Electronic Signatures – JAdES) y verificación del enlace. Y supondría también más trabajo para los administradores de sitios Web, si no fuera porque ya va a ser imprescindible adoptar herramientas de automatización como «ACME». ACME (Automated Certificate Management Environment) es un protocolo estandarizado que permite la automatización de la emisión, renovación y revocación de certificados TLS/SSL.

El enfoque 2-QWAC es el que se adoptaría por los Prestadores Cualificados de Servicios de Confianza europeos que no quisieran pasar por el procedimiento de aprobación de Bugzilla, CCADB, Baseline Requirements y Extended Validation Guidelines.

De esta manera, no se cambian los procedimientos de CAB Forum y de los programas de CA-Raíz convencionales de los navegadores, pero se establece un marco técnico para que se puedan aceptar certificados cualificados de web «puros» en la Unión Europea (apoyados, no obstante, en certificados emitidos por jerarquías PKI incluidas en dichos programas de Root-CA de los navegadores).

El acto de ejecución mencionado (en estado «borrador» incorpora el siguiente anexo:

Draft-Imp-Act-Annex-QWACDescarga

Llama a EADTrust al 902 365 612 o al +34917160555 para saber más.

Próximos eventos «Trust Services and eID Forum» y «CA-day» en Split, Croacia el 24 y 25 de septiembre de 2025

Deja un comentario

El 24 de septiembre de 2025, ENISA organiza el 11º Foro sobre Servicios de Confianza y Identificación Electrónica (11th Trust Services and eID Forum). El 25 de septiembre de 2025, D-TRUST, en colaboración con TÜV Nord Cert, celebrará la 17ª Jornada de CAs (17th CA-Day).

¿A quién va dirigido?

El foro, organizado en colaboración con la Comisión Europea desde 2015, se ha convertido en «la cita ineludible» para las partes interesadas del amplio ámbito del Reglamento eIDAS. Reúne a responsables políticos, prestadores de servicios de confianza, organismos de evaluación de la conformidad, supervisores, instituciones europeas y de los Estados miembros y usuarios finales interesados, ofreciendo un lugar único para los debates relacionados con las identidades digitales en Europa. Este año, el evento se traslada a Split, Croacia, y se garantiza también la retransmisión en línea para la participación virtual.

Contenido

Entre los temas que se debatirán este año, abordaremos los siguientes

  • Normalización y certificación de la Cartera de Identidad Digital Europea
  • Interacción de eIDASv2 con otra legislación (CRA, Ley de Chips de la UE, NISD2), incluidos los aspectos relacionados con la privacidad
  • Aplicación de los servicios de confianza nuevos y previamente definidos, desde el punto de vista técnico y organizativo
  • Nuevas necesidades de colaboración entre todos los servicios de confianza y las partes interesadas en la identificación electrónica
  • Estrategias para promover el mercado de la identidad digital

Como en años anteriores (desde 2018), el Trust Services and eID Forum irá seguido del CA-Day, organizado por D-Trust y TÜV Nord Cert, que tendrá lugar el 25 de septiembre en el mismo lugar.

Agenda en inglés

El borrador del programa ya está disponible. Contiene interesantes presentaciones y cautivadores debates entre expertos reconocidos en la materia. Tenga en cuenta que se seguirá actualizando en las próximas semanas. Ver la traducción más abajo

Inscripción

Ya puede reservar su plaza inscribiéndose aquí. Reserve su plaza presencial solo si está seguro de que podrá asistir al evento en persona. Tenga en cuenta que no es posible acoger presencialmente a más de 2-3 participantes de la misma organización.

Agenda en español

11th TSF – 17th CA Day – Agenda 20250804-ESDescarga

Certificados cualificados para PSD2 (Segunda Directiva de Servicios de Pago)

Deja un comentario

Los certificados PSD2 son certificados digitales cualificados diseñados para cumplir con la Directiva de Servicios de Pago (PSD2) de la Unión Europea. Estos certificados aseguran las transacciones financieras y la comunicación entre los proveedores de servicios de pago y las instituciones financieras.

Tipos de certificados PSD2

Existen dos tipos principales de certificados PSD2:

  1. QWAC (Qualified Website Authentication Certificate):
    • Autentifica el sitio web del proveedor de servicios de pago.
    • Cifra las comunicaciones entre el banco y el proveedor mediante conexión TLS.
    • Garantiza la comunicación segura en la transmisión de datos.
  2. QSealC (Qualified eSeal Certificate):
    • Securiza los datos a nivel de aplicación.
    • Identifica de forma unívoca quién ha accedido a la API.
    • Protege los datos firmados contra modificaciones, asegurando su integridad.

Información contenida

Los certificados PSD2 incluyen:

  • Identidad del proveedor de servicios de pago.
  • Roles del proveedor (pueden ser uno o varios: AISP, PISP,…).
  • Número de autorización asignado por la Autoridad Nacional Competente.
  • Nombre del dominio/dominios autenticados

Requisitos para su expedición

Para obtener un certificado PSD2, se requiere:

  1. Ser un proveedor de servicios de pago autorizado con un número de autorización asignado por la Autoridad Nacional Competente (en España, el Banco de España).
  2. Presentar documentación:
    • Documento de identificación (DNI, NIE) del representante legal.
    • Poder que acredite la representación vigente.
    • Identificación de la categoría de la entidad (organización privada, entidad gubernamental, comercial o no comercial)910.
  3. Pasar por un proceso de validación, similar al requerido para TLS de validación extendida (EV), que puede incluir:
    • Verificación cara a cara de los documentos oficiales del titular del certificado.
    • Confirmación de la licencia y roles del proveedor de servicios de pago por parte de la autoridad certificadora6.
  4. En algunos casos, se puede requerir la intervención de un notario público para facilitar el proceso de validación6.

Los certificados PSD2 son cruciales para garantizar la seguridad y la confianza en las transacciones financieras digitales en el marco de la normativa europea, proporcionando autenticación, integridad y confidencialidad en las comunicaciones entre proveedores de servicios de pago, bancos y clientes.

Final text of article 45 in #EIDAS2 Regulation

Deja un comentario

Today has been published the final text adopted for EIDAS2 Regulation in the last Triloge meeting, last week.

This is the text of Article 45

Article 45 – Requirements for qualified certificates for website authentication

  1. Qualified certificates for website authentication shall meet the requirements laid down in Annex IV. Evaluation of compliance with those requirements shall be carried out in accordance with the standards and the specifications referred to in paragraph 3.
  2. Qualified certificates for website authentication issued in accordance with paragraph 1 shall be recognised by web-browsers. ▌Web-browsers shall ensure that the identity data attested in the certificate and additional attested attributes are displayed in a user-friendly manner. Web-browsers shall ensure support and interoperability with qualified certificates for website authentication referred to in paragraph 1, with the exception of enterprises ▌ considered to be microenterprises and small enterprises in accordance with Commission Recommendation 2003/361/EC during the first 5 years of operating as providers of web-browsing services.
    ▌
    2b. Qualified certificates for website authentication shall not be subject to any mandatory requirements other than the requirements laid down in paragraph 1
  3. By … [12 months after the date of the entering into force of this amending Regulation], the Commission shall, by means of implementing acts, establish a list of reference standards and when necessary, establish specifications and procedures for qualified certificates for website authentication, referred to in paragraph 1. ▌ Those implementing acts shall be adopted in accordance with the examination procedure referred to in Article 48(2).”

Article 45a-1 – Cybersecurity precautionary measures

  1. Web-browsers shall not take any measures contrary to their obligations set out in Article 45, notably the requirement to recognise Qualified Certificates for Website Authentication, and to display the identity data provided in a user friendly manner.
  2. By way of derogation to paragraph 1 and only in case of substantiated concerns related to breaches of security or loss of integrity of an identified certificate or set of certificates, web-browsers may take precautionary measures in relation to that certificate or set of certificates.
  3. Where measures are taken, web-browsers shall notify their concerns in writing without undue delay, jointly with a description of the measures taken to mitigate those concerns, to the Commission, the competent supervisory authority, the entity to whom the certificate was issued and to the qualified trust service provider that issued that certificate or set of certificates. Upon receipt of such a notification, the competent supervisory authority shall issue an acknowledgement of receipt to the web-browser in question.
  4. The competent supervisory authority shall consider the issues raised in the notification in accordance with Article 17(3)(c). When the outcome of that investigation does not result in the withdrawal of the qualified status of the certificate(s), the supervisory authority shall inform the web-browser accordingly and request it to put an end to the precautionary measures referred to in paragraph 2.

Where can I find the proposed article 45 of #eIDAS2 regulation

Deja un comentario

These days I have seen magazine articles, blog posts and tweets complaining about article 45 of the #eIDAS2 regulation that is about to be approved in the Triloge process.

Almost all of them echo Mozilla’s statements about Article 45, announcing a hecatomb on the security of web browsing and claiming that it is the door that opens to governments the possibility of spying on citizens.

But how curious! No article or blog post includes the text of Article 45 of the future #eIDAS2 regulation to analyze it and explain why its ominous predictions can be deduced from the proposed text.

So the purpose of this blog post is precisely to include the text of article 45 of the future #eIDAS2 regulation so that anyone can analyze it on their own, without having to accept the arguments of one side or the other.

This is one of the latest versions used in the trilogues.

«Article 45

Requirements for qualified certificates for website authentication

  1. Qualified certificates for website authentication shall allow the authentication and identification of the natural or legal person to whom the certificate was issued with a high level of assurance. Qualified certificates for website authentication shall also meet the requirements laid down in Annex IV. Qualified certificates for website authentication shall be deemed compliant with this paragraph and the requirements laid down in Annex IV where they meet the standards referred to in paragraph 3.
  2. Qualified certificates for website authentication referred to in paragraph 1 shall be recognised by web-browsers. Web browsers shall not be prevented from taking measures that are both necessary and proportionate to address substantiated risks of breaches of security, user’s privacy and loss of integrity of certificates provided such measures are duly reasoned. In such a case, the web browser shall notify the Commission, ENISA and the qualified trust service provider that issued that certificate or set of certificates without delay of any measure taken. Such recognition means that web-browsers shall ensure that the relevant identity data and electronic attestation of attributes provided is displayed in a user friendly manner, where possible, consistent manner, that reflects the state-of-the-art regarding accessibility, user awareness and cybersecurity according to best industry standards. Web-browsers shall ensure support and interoperability with qualified certificates for website authentication referred to in paragraph 1, with the exception of enterprises, considered to be microenterprises and small enterprises in accordance with Commission Recommendation 2003/361/EC in the first 5 years of operating as providers of web-browsing services.
  3. By … [12 months after the date of entry into force of this amending Regulation], the Commission shall, by means of implementing acts, provide the specifications and reference numbers of standards for qualified certificates for website authentication referred to in paragraph 1 and 2. Those implementing acts shall be adopted in accordance with the examination procedure referred to in Article 48(2).»

El lobby de Mozilla ataca el futuro artículo 45 del Reglamento EIDAS 2 y aquí explico por qué está equivocado

2 respuestas

Durante el fin de semana del 4 y 5 de noviembre de 2023 se ha publicado un «Joint Statement» impulsado por Mozilla e Internet Society, como parte de su esfuerzo de influenciar el desarrollo legislativo del Reglamento EIDAS2 en fase de Trílogos.

Entre otras afirmaciones, dice:

«Después de leer el texto casi definitivo, estamos profundamente preocupados por el texto propuesto para el artículo 45. La propuesta actual amplía radicalmente la capacidad de los gobiernos para vigilar tanto a sus propios ciudadanos como a los residentes en toda la UE, proporcionándoles los medios técnicos para interceptar el tráfico web cifrado, además de socavar los mecanismos de supervisión existentes en los que confían los ciudadanos europeos»

El artículo 45 se formuló de la siguiente forma en la versión inicial de la propuesta de reglamento:

«Artículo 45

Requisitos de los certificados cualificados de autenticación de sitios web

  1. Los certificados cualificados de autenticación de sitios web cumplirán los requisitos establecidos en el anexo IV. Se presumirá el cumplimiento de los requisitos establecidos en el anexo IV cuando un certificado cualificado de autenticación de sitios web se ajuste a las normas a que se refiere el apartado 3.
  2. Los navegadores web reconocerán los certificados cualificados de autenticación de sitios web a que se refiere el apartado 1. Con este fin, los navegadores web garantizarán que los datos de identificación proporcionados mediante cualquiera de los métodos se muestren al usuario de un modo fácil de entender. Los navegadores web garantizarán la compatibilidad e interoperabilidad con los certificados cualificados de autenticación de sitios web a que se refiere el apartado 1, con la excepción de las empresas consideradas microempresas y pequeñas empresas de conformidad con la Recomendación 2003/361/CE de la Comisión en sus primeros cinco años de actividad como prestadores de servicios de navegación web.
  3. Dentro de los doce meses siguientes a la entrada en vigor del presente Reglamento, la Comisión dispondrá, por medio de actos de ejecución, las especificaciones y los números de referencia de las normas para los certificados cualificados de autenticación de sitios web a que se refiere el apartado 1. Estos actos de ejecución se adoptarán con arreglo al procedimiento de examen contemplado en el artículo 48, apartado 2.»

A lo largo del proceso legislativo se han propuesto algunos cambios, entre otras razones porque la actuación del lobby no es de ahora y se pensó en aceptar lo aceptable de sus planeamientos. Al inicio de los debates de los trílogos (en marzo de 2023) el texto propuesto era:

«Article 45

Requirements for qualified certificates for website authentication

  1. Qualified certificates for website authentication shall allow the authentication and identification of the natural or legal person to whom the certificate was issued with a high level of assurance. Qualified certificates for website authentication shall also meet the requirements laid down in Annex IV. Qualified certificates for website authentication shall be deemed compliant with this paragraph and the requirements laid down in Annex IV where they meet the standards referred to in paragraph 3.
  2. Qualified certificates for website authentication referred to in paragraph 1 shall be recognised by web-browsers. Web browsers shall not be prevented from taking measures that are both necessary and proportionate to address substantiated risks of breaches of security, user’s privacy and loss of integrity of certificates provided such measures are duly reasoned. In such a case, the web browser shall notify the Commission, ENISA and the qualified trust service provider that issued that certificate or set of certificates without delay of any measure taken. Such recognition means that web-browsers shall ensure that the relevant identity data and electronic attestation of attributes provided is displayed in a user friendly manner, where possible, consistent manner, that reflects the state-of-the-art regarding accessibility, user awareness and cybersecurity according to best industry standards. Web-browsers shall ensure support and interoperability with qualified certificates for website authentication referred to in paragraph 1, with the exception of enterprises, considered to be microenterprises and small enterprises in accordance with Commission Recommendation 2003/361/EC in the first 5 years of operating as providers of web-browsing services.
  3. By … [12 months after the date of entry into force of this amending Regulation], the Commission shall, by means of implementing acts, provide the specifications and reference numbers of standards for qualified certificates for website authentication referred to in paragraph 1 and 2. Those implementing acts shall be adopted in accordance with the examination procedure referred to in Article 48(2).»

El texto final se ha acordado en los debates de trílogos y la reunión final para decidir su aprobación está prevista para el miércoles 8 de noviembre, bajo la presidencia española. No sé exactamente el texto acordado pero será parecido al ya indicado.

El debate ha dado lugar a un documento específico del Parlamento Europeo analizando las distintas posiciones. Es de enero de 2023.

La dureza (y falsa información) del ataque de Mozilla e «Internet Society» ha motivado que un grupo de prestadores de servicios de certificación europeos («European Signature Dialog») hayan preparado un documento de respuesta.

La campaña de los útimos dias de este Lobby ha llegado a los medios de comunicación: EU digital ID reforms should be ‘actively resisted’, say experts

Como respuesta, hoy «European Signature Dialog» ha publicado otro documento parecido al de hace unos días:

esd-experts-support-trilogue-art.45-results-6nov2023Descarga

Los diversos documentos difundidos por «Mozilla», son básicamente falsos. Combinan mentiras y desinformación y atacan el hecho de que una norma tan importante como un Reglamento Europeo obligue a que los navegadores web estén obligados a reconocer los certificados cualificados de autenticación de sitios web.

Sin embargo esto se reconoce en el contexto de los Prestadores de Servicios de Confianza Digital Cualificados como una necesidad inaplazable.

Lo que pasa en realidad es que los Prestadores de Servicios de Confianza (entre los cuales están los Servicios de Certificación, entre los cuales los certificados para servidores web son un caso particular) deben superar un duro proceso de revisión que incluye una auditoría bienal (por un Organismo Evaluador de Conformidad, CAB) para todos sus servicios cualificados más una auditoría anual para los servicios de emisión de certificados de sitio web.

Luego deben presentar el Informe de Evaluación de Conformidad (CAR) al Organismo Supervisor del país en el que prestan sus servicios (que podría imponer requisitos adicionales).

Y ADEMÁS deben solicitar al organismo de Evaluación que genere un CAR parecido con algunos requisitos ligeramente diferentes para la inclusión de sus certificados en las listas de confianza de los navegadores a través de ciertos mecanismos como la base de datos CCADB y la plataforma de gestión de errores Bugzilla. Esta plataforma, auspiciada por Mozilla, la usan otras entidades que desarrollan navegadores web.

En la evaluación de conformidad se toman en consideración las normas de ETSI EN 319 401, EN 319 411 (1 y 2, especialmente -1-), EN 319 412 (1 a 5, especialmente -4-) y TS 119 403-2 que a su vez subsumen las normas de CABForum «Baseline requirements» y «Extended Validation Guidelines».

Un proceso que se ha impuesto desde la entrada en vigor del Reglamento EIDAS (1) publicado en 2014 y con el que llevamos casi 10 años. Es un proceso claramente redundante que además tiene un alto grado de inseguridad jurídica porque en las discusiones de Bugzilla opinan quienes tanto tienen conocimientos adecuados como los que no los tienen, lo que lleva a veces a no permitir alegar a los prestadores cuando se les acusa de un comportamiento inadecuado y donde aparecen requisitos no escritos porque a alguien se le ocurre.

El artículo 45 dice, básicamente, que si un prestador de servicios de confianza ya se ha auditado en base a todos los requisitos que aplican y su Organismo Supervisor lo ha validado hasta el punto de incluirlo en la TSL (Lista de Servicios de Confianza), entonces los navegadores deben aceptarlo e incluirlo en sus propias listas de Confianza.

Si una vez en vigor el nuevo artículo 45 alguien  (un particular, una universidad o un fabricante de navegadores) detecta un problema en un servicio de emisión de certificados europeo, solo tiene que notificarlo motivadamente al Organismo Supervisor que actuará en consecuencia solicitando información al prestador, y retirándole la confianza si fuera preciso, eliminándolo de la TSL. Seguramente se puede automatizar el aviso desde Bugzilla para que los navegadores acostumbrado a ese mecanismo no tengan que cambiar sus procedimientos.

15TH CA-DAY

Deja un comentario

Hoy, 12 de octubre de 2023, ha tenido lugar el decimoquinto «Dia de los Servicios de Certificación» (15TH CA-DAY). Este evento está asociado con el que se celebró ayer: el noveno Foro de los Servicios de Confianza e Identidad Digital (9th Trust Services and eId Forum).

El principal objetivo de estas jornadas es abordar los últimos avances en el marco de eIDAS2, los servicios de confianza en virtud de la Directiva NIS2, la próxima implementación de la Cartera Digital de la UE, así como la solución tecnológica con el fin de proporcionar servicios en línea seguros a los ciudadanos de la UE.

08:00 – 09:00Registrations and breakfast 
09:00 – 09:15Welcome by D-Trust and TÜVITKim Nguyen
Dirk Kretzschmar
09:15 – 09:30Keynote Andrea Valle, Adobe
09:30 – 09:50eIDAS 2.0 – What is new for TSP? Viky Manaila, Intesi Group
09:50 – 10:10NIS II and eIDAS II: How to audit Trust Services in 2025? Paloma Llaneza González, CerteIDAS
10:10 – 10:30QWACs and QSeals Identifying Reliable SourcesEnrico Entschew, D-Trust
Andreas Wand, D-Trust
10:50 – 11:10Auditing TSP Services in the Cloud Matthias Wiedenhorst, TÜVIT
11:10 – 11:30European Cyber regulations at a glance Slawomir Gorniak, ENISA
11:30 – 11:50Remote identification under eIDAS Jon Olnes, Signicat
11:50 – 12:10Wallet use cases for TSPsMichal Tabor, Obserwatorium.biz
12:30 – 12:50SSI and PKI – enabling attribute attestationsChristian Seegebarth, IDunion
12:50 – 13:10eIDAS 2.0 Toolbox: Selective Disclosure for EAA Sebastian Elfors, IDNow
13:10 – 13:30Post Quantum Cryptography Jan Klaußner, Bundesdruckerei
14:30 – 14:50CAB-Forum Updates and S/MIME Baseline RequirementsDimitris Zacharopoulos, CA/Browser-Forum
14:50 – 15:10International market for trust servicesDean Coclin, DigiCert
15:10 – 15:50Panel Discussion +Q&A: TSP governance – European vs. Root storesDennis Jackson, Mozilla
Jochen Eisinger, GoogleArno Fiedler, Nimbus Technologieberatung
Paul van Brouwershaven, Entrust
Kim Nguyen, D-Trust
15:50 – 16:00Closing remarksKim Nguyen,
Arno Fiedler

Al finalizar estos dos días quedan muchas inquietudes por resolver y algunas ideas:

  • El 4 de noviembre comenzará el debate final de los Trílogos sobre Identidad Digital con previsión de que el nuevo Reglamento (EIDAS2) se publique en Diciembre de 2023.
  • La Cartera Digital enfrenta como mayor reto la adopción.
  • La estructura de Prestadores de Servicios de expedición de testimonios cualificados presenta muchos retos e incertidumbres
  • No está claro aun como se evaluará la seguridad de la Cartera Digital ni los Servicios de expedición de testimonios cualificados.

New EIDAS Regulation makes clear to web-browsers that they must recognize qualified website authentication certificates

Deja un comentario

New draft proposal to ammend Regulation (UE) No 910/2014 (EIDAS) replace Article 45 withe the following text:

Requirements for qualified certificates for website authentication

  1. Qualified certificates for website authentication shall meet the requirements laid down in Annex IV. Qualified certificates for website authentication shall be deemed compliant with the requirements laid down in Annex IV where they meet the standards referred to in paragraph 3.
  2. Qualified certificates for website authentication referred to in paragraph 1 shall be recognised by web-browsers. For those purposes web-browsers shall ensure that the identity data provided using any of the methods is displayed in a user friendly manner. Web-browsers shall ensure support and interoperability with qualified certificates for website authentication referred to in paragraph 1, with the exception of enterprises, considered to be microenterprises and small enterprises in accordance with Commission Recommendation 2003/361/EC in the first 5 years of operating as providers of web-browsing services.
  3. Within 12 months of the entering into force of this Regulation, the Commission shall, by means of implementing acts, provide the specifications and reference numbers of standards for qualified certificates for website authentication referred to in paragraph 1.  Those implementing acts shall be adopted in accordance with the examination procedure referred to in Article 48(2).’;

Comunicación de Mozilla a las Autoridades de Certificación

Deja un comentario

La Fundación Mozilla ha enviado una comunicación a  las Autoridades de Certificación para informar a las CAs que tienen certificados raíz incluidos en el programa de Mozilla en relación con acciones planificadas y las fechas prevista.

La comunicación a las CAs se ha enviado por correo electrónico al Punto de contacto principal  y a un alias de correo electrónico para cada CA del programa de Mozilla, y se les ha pedido que respondan a las siguientes 7 acciones planificadas:

  1. Leer y cumplir plenamente con la versión 2.7 de la Política de la Repositorio  Raíz de Confianza de Mozilla.
  2. Asegurarse de que sus CP y CPS cumplen con la sección 3.3 de la política actualizada que requiere indicar de forma adecuada cuando no aplica un apartado y el mapeo de los documentos de la política a los certificados de las CA.
  3. Confirmar su intención de cumplir con la sección 5.2 de la política de repositorio raíz de Confianza de Mozilla que requiere que los nuevos certificados de entidad final incluyan una extensión EKU que exprese su uso previsto.
  4. Verificar que sus declaraciones de auditoría cumplen los requisitos de formato de Mozilla que facilitan el procesamiento automatizado.
  5. Resolver los problemas con las auditorías de los certificados de CA intermedios que han sido identificados por el sistema automatizado de validación de informes de auditoría.
  6. Confirmar el conocimiento de los requisitos de informes de incidentes de Mozilla y la intención de proporcionar buenos informes de incidentes.
  7. Confirmar el cumplimiento de la versión actual de los requisitos básicos del foro de navegadores y CAs.

Los elementos de acción completos pueden leerse aquí. Las respuestas a la encuesta serán publicadas automática e inmediatamente por la CCADB.

Aunque la participación en el Programa de certificados de CA de Mozilla se somete al criterio de la Fundación Mozilla que puede excluir una CA discrecionalmente, parece que el mejor enfoque para salvaguardar la seguridad de los usuarios es trabajar con las CA como colaboradores, en vez de como adversarios, fomentando una comunicación abierta y franca, y que busque el encuentro al identificar formas de mejorar.