Resumen

  • RFC 10007 actualiza el paso de validación de CRL de RFC 5280: si el certificado del emisor es v3, debe incluir keyUsage y activar cRLSign.
  • El cambio evita que una segunda clave del mismo sujeto sea aceptada para firmar una CRL solo porque su nombre coincide, su cadena es válida y su certificado omitió la extensión que habría limitado el uso.
  • La aplicación brusca puede rechazar emisores heredados que se creían legítimos; la CA debe reparar la emisión y el operador debe demostrar que conserva cobertura de revocación.

La diferencia que una comparación de nombres no puede ver

El caso descrito por RFC 10007 empieza con el sujeto X. La CA certifica la clave A para firmar listas de revocación: el certificado contiene keyUsage y marca cRLSign. Más tarde certifica otra clave B para un uso corriente, con el mismo sujeto X, pero sin keyUsage.

Unos certificados indican que X es el emisor indirecto de su CRL. X firma después una lista con B. El nombre encaja, la ruta de certificación de B puede llegar a la misma ancla y la firma puede verificarse. La autorización de esa clave concreta, sin embargo, nunca existió.

El registro de RFC 10007 identifica la publicación de junio de 2026 como actualización de RFC 5280. El texto anterior de RFC 5280 decía que se comprobara cRLSign si la extensión keyUsage estaba presente. Al faltar la extensión, faltaba también la comprobación. La ficha de RFC 5280 convive con una regla de emisión que ya exigía la extensión a las claves usadas para validar certificados o CRL.

RFC 10007 cierra la asimetría: en un certificado v3 no basta con mirar el bit cuando aparece; hay que exigir la extensión y después el bit. Los certificados v1 y v2 no tienen campo de extensiones, de modo que el nuevo paso no les exige un dato imposible.

Identidad, clave y finalidad son afirmaciones distintas

La clave B no tiene que pertenecer a un impostor para que el resultado sea incorrecto. Puede pertenecer de verdad al sujeto X. El defecto consiste en convertir identidad en mandato operativo.

RFC 4514 normaliza la representación textual de nombres distinguidos para LDAP. Su ficha no dice que un DN sea una huella de clave ni que todas las claves bajo ese nombre sean equivalentes. Un mismo sujeto puede tener certificados distintos para correo, documentos, autenticación o revocación.

RFC 5280 da significado separado a digitalSignature, keyCertSign y cRLSign. Este último declara que la clave puede verificar firmas de CRL, delta CRL y listas de revocación de autoridad. La posibilidad matemática de firmar no sustituye a la finalidad certificada.

El texto en Datatracker, el historial del borrador, la carta de LAMPS y su historia documentan proceso, revisión y alcance. No prueban qué bibliotecas aplican hoy la regla ni cuántos emisores cumplen.

Una CRL indirecta necesita más que una firma correcta

Cuando el emisor de la CRL no es la CA que emitió el certificado examinado, el punto de distribución puede nombrar un cRLIssuer. La extensión crítica issuingDistributionPoint de la lista declara el carácter indirecto y acota usuarios, CA, motivos o punto de distribución.

El consumidor debe alinear al menos nombre del emisor, indicador indirecto, alcance, ancla, cadena, firma, finalidad, tiempo y cobertura de motivos. RFC 10007 repara la finalidad. No convierte un certificado con cRLSign en prueba de que la lista sea actual, completa, accesible o correcta.

El marco de RFC 3647 es útil porque separa CA, autoridad de registro, repositorio, suscriptor y parte que confía, además de política, prácticas, auditoría y disponibilidad del servicio de estado. Su registro impide reducir todo ese sistema a una comprobación criptográfica.

El nuevo rechazo puede descubrir una deuda legítima

RFC 10007 advierte que una aplicación actualizada no podrá verificar una CRL si el certificado v3 de su emisor se destinaba a ese trabajo pero omitió keyUsage. El certificado estaba mal perfilado aunque la intención operativa fuera legítima.

La CA debe identificar esos emisores, reemitir certificados correctos, mantener solapamiento suficiente y retirar los antiguos con evidencia. Si el perfil no puede modificarse, la autoridad de política puede exigir nombres distintos para usos distintos. Esa salida reduce la colisión descrita, pero no demuestra custodia, alcance ni actualidad.

También importa el significado del fallo. Una CRL rechazada no demuestra que el certificado objetivo esté revocado. Significa que esa fuente no ofrece una prueba aceptable; el estado puede quedar indeterminado. Las aplicaciones que solo admiten “bueno” o “revocado” esconden el riesgo en uno de esos dos extremos.

OCSP tiene su propia autorización. RFC 6960 exige firma directa de la CA, configuración local o una delegación certificada con id-kp-OCSPSigning bajo condiciones concretas. Su ficha no convierte el protocolo en sustituto automático. RFC 6818 y su registro muestran otra actualización de RFC 5280 y confirman que mantenimiento documental y despliegue son capas distintas.

El estándar fija el invariante; la red ejecuta el cambio

La primacía del código en ejecución de Lu Heng ofrece la prueba operativa: una publicación no repara certificados ni cambia validadores. Su marco de especificación mínima, decisión localizada y adopción voluntaria reserva al plano común las reglas de seguridad deterministas y deja la secuencia de adopción a quienes soportan el resultado.

Exigir cRLSign en v3 es una regla fina y verificable localmente. Aplicarla bien exige inventario, vectores negativos, despliegue limitado, observación y salida. La autoridad de la norma no sustituye la responsabilidad del operador.

Fuentes