Perfiles de certificado digital de la Ley 11/2007

dolor de cabezaLos dolores de cabeza que ha traido a los Prestadores de Servicios de Certificación (PSC) adecuarse a los perfiles de los tipos de certificados definidos en la Ley 11/2007, de 22 de junio, de Acceso Electrónico de los Ciudadanos a los Servicios Públicos (L11/2007) han acabado con las existencias de analgésicos de los botiquines de las empresas.

En concreto me refiero a los perfiles definidos en el Esquema de identificación y firma electrónica de las Administraciones públicas Bloque I: Perfiles de certificados electrónicos, que define los perfiles de los certificados anteriores, documento cuyas modificaciones respecto a su versión anterior ya hablamos en el pasado.

Vaya por delante que este documento seguro que se ha desarrollado con la mejor voluntad, buscando el máximo consenso y el mínimo impacto entre los diferentes actores del mercado, y también que cada decisión tiene detrás horas de diseño y una clara justificación. No obstante, por no haber participado en la definición de estos perfiles, se me escapa qué razonamiento hay detrás de determinadas decisiones.

Uso de las extensiones qcStatements

Los tipos de certificados identificados en la L11/2007 son:

  1. Sede electrónica
  2. Sello electrónica
  3. Personal al servicio de la administración pública

Sólo el tercero es claramente de persona física, el primero no contiene ningún dato de carácter personal y en el segundo es opcional. Entonces, ¿cómo puede ser que sean obligatorias las extensiones qcStatments, reservadas para certificados reconocidos, si un certificado reconocido debe contener, según interpretación del Ministerio de Indústria, Turimos y Comercio (MITyC) de la LFE, SIEMPRE, la identificación de la persona física con su nombre, apellidos y NIF?

Para mi se trata de una incongruencia y se le da mal uso a unas extensiones cuyo uso era bastante claro hasta el momento.

Identidad Administrativa

Duplicación de información

Son una serie de OIDs privados, que en el caso de los certificados de personal al servicio de la administración pública (de empleado público) son la friolera de once (11), a saber:ristra pimientos

  1. OID: 2.16.724.1.3.5.3.2.1 = “certificado electrónico de empleado público”
  2. OID: 2.16.724.1.3.5.3.2.2 = <O del DN>
  3. OID: 2.16.724.1.3.5.3.2.3 = <CIF de la entidad suscriptora>
  4. OID: 2.16.724.1.3.5.3.2.4 = <serialNumber del DN>
  5. OID: 2.16.724.1.3.5.3.2.5 = Número de identificación del suscriptor del certificado (supuestamente unívoco). Se corresponde con el NRP o NIP. (tercera entrada <OU del DN>)
  6. OID: 2.16.724.1.3.5.3.2.6 = <Given name>
  7. OID: 2.16.724.1.3.5.3.2.7 = <Primer apellido del empleado público>
  8. OID: 2.16.724.1.3.5.3.2.8 = <Segundo apellido del empleado público>
  9. OID: 2.16.724.1.3.5.3.2.9 = <correo electrónico del empleado público>
  10. OID: 2.16.724.1.3.5.3.2.10 = Unidad, dentro de la Administración, en la que está incluida el suscriptor del certificado (segunda entrada <OU del DN>)
  11. OID: 2.16.724.1.3.5.3.2.11 = <T del DN>

Como puede verse en la lista comparativa anterior, toda la información que contienen estos campos ya se encuentran en otros campos del certificado. Es verdad que, por ejemplo, poner el NRP o NIP como una tercera entrada de OU del DN es, si no pervertir, retorcer el propósito inicial del campo OU, pero en general, el resto de información está bien colocada en campos estándares, sin necesidad de duplicarla

Numeración de los OIDs

lío en el certificado electrónicoOtra cosa que me llama la atención es la numeración de estos OIDs. Los seis (6) primeros campos son comunes (2.16.724.1.3.5.), y luego se usan tres posiciones más (m.n.o), que indican lo siguiente:

  • m: 1 – sede electrónica, 2 – sello electrónico, 3 – empleado público
  • n: 1 – nivel alto, 2 – nivel medio (cuando sólo hay dos niveles, ¿porqué se le llama a uno alto y a otro medio?, ¿no es «medio» un eufemismo en esta situación?
  • o: 1..5 para sede electrónica, 1..9 en el caso de certificados de sello electrónico, 1..11 para los certificados de empleado público. Estos campos contienen la información redundante de la que hablábamos más arriba.

Esto nos lleva a manejar 5 (campos privados de sede)x2 (niveles) + 9×2 +11×2 = 50 OIDs privados. Esta es la realidad.

El otro extremo

Si nos ponemos ahorradores, manteniendo la interoperabilidad y sin pervertir campos estándares, sólo serían necesarios dos (2) campos adicionales, por ejemplo:

  1. OID: 2.16.724.1.3.5.3.1, con valores: 1 – sede nivel alto, 2 – sede nivel «medio», 3 – sello nivel alto, 4 – sello nivel «medio», 5 – empleado público nivel alto, 6 – empleado público nivel «medio»
  2. OID: 2.16.724.1.3.5.3.2, conteniendo el el NRP o NIP

Una alternativa menos ahorradora y que facilita más la interoperabilidad sería añadir un par de campos más:

  1. OID: 2.16.724.1.3.5.3.3, CIF de la entidad
  2. OID: 2.16.724.1.3.5.3.4, NIF de la persona física cuando proceda

En resumen, pienso que estos perfiles podían haber sido más sencillos y adherirse mejor a los estándares de uso de los campos de un certificado X.509v3.

Comments are welcome.

¿Te ha gustado lo que contamos?
Comparte con tus amigos