El CAB Forum ha aprobado una modificación del documento «Extended Validation Guidelines» para permitir incluir guiones en el campo organizationIdentifier (OID 2.5.4.97) de los certificados EV (Extended Validation), 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 compatibles con EV 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 Cualificado 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, VAT, 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 organizationIdentifier 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 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 explícitam 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 «.