Resumen

  • El perfil de RFC 5280 pedía keyUsage con cRLSign para las claves que firman CRL, pero el algoritmo de validación solo ordenaba revisar el bit si la extensión estaba presente.
  • RFC 10007 obliga a comprobar, en certificados v3, tanto la presencia de la extensión como el bit. Firma, DN y ruta válidos prueban hechos distintos de la autorización de uso.
  • El recibo operativo debe guardar versión y clave elegida, presencia de la extensión, ámbito y vigencia de la CRL, resultados de ruta y firma, estado del certificado objetivo y cualquier excepción heredada.

El fallo no estaba en una operación criptográfica. Estaba en una pregunta que podía no formularse.

RFC 5280 describía qué debía contener un certificado destinado a verificar firmas de listas de revocación: la extensión keyUsage, marcada como critical, con cRLSign activo. Pero su procedimiento posterior decía que, si la extensión estaba presente, se comprobara el bit. El matiz permitía que un programa tratase la ausencia de todo el campo como una razón para saltarse el control.

Corey Bonnell, Tadahiko Ito y Tomofumi Okubo abordaron ese hueco en RFC 10007, publicada en junio de 2026 como Standards Track y actualización de RFC 5280. Bonnell figura primero entre los tres autores. Es una contribución personal documentada dentro de un consenso colectivo del IETF, no una atribución exclusiva ni una auditoría de todos los programas que procesan CRL.

La otra clave del mismo sujeto

La norma explica el riesgo sin recurrir a un atacante que suplanta una identidad. Una CA delega en el sujeto X la firma de CRL indirectas. Certifica la clave A de X e incluye keyUsage con cRLSign. Los certificados cubiertos apuntan al DN de X en el campo cRLIssuer de su punto de distribución.

Después, la CA certifica una clave B para el mismo X. B se destina a una tarea ordinaria y su certificado no contiene keyUsage. No cambia el nombre del sujeto. La ruta de B también puede ser válida y terminar en la misma ancla.

Si X firma una CRL con B, la comprobación matemática puede pasar. El DN del emisor puede coincidir. Lo que no existe es una afirmación de que B esté certificada para firmar CRL. La autorización de A no se transmite por compartir nombre.

La diferencia parece pequeña hasta que se automatiza. Una plataforma puede resumir «certificado válido + firma válida» como «emisor autorizado». En realidad, el primer resultado vincula una clave a un sujeto dentro de una ruta y el segundo vincula esa clave a unos bytes. El permiso para el acto depende de otro dato.

Una ausencia más permisiva que un no

Con la redacción antigua, un certificado que incluía keyUsage pero no cRLSign era rechazado. En cambio, uno sin la extensión podía evitar el control. La ausencia obtenía un trato mejor que una restricción explícita.

Es un patrón peligroso en cualquier validador: se verifica el valor de una propiedad opcional, pero no se verifica que sea obligatoria en ese contexto. La interfaz acaba mostrando un resultado positivo derivado de no haber observado nada.

RFC 10007 cambia el paso para los certificados v3. Primero debe verificarse que keyUsage está presente; luego, que cRLSign está activo. Conviene que el registro mantenga ambos hechos. Una extensión ausente apunta a un perfil incorrecto o a una selección equivocada del certificado. Una extensión presente sin el bit expresa una finalidad distinta.

La ruta de reparación también cambia. En un caso quizá haya que reemitir el certificado destinado a CRL; en el otro se puede haber elegido una credencial de otro uso. Ocultarlos bajo «fallo de clave» impide decidir.

El límite de las versiones anteriores

Los certificados X.509 v1 y v2 carecen de campo de extensiones. RFC 10007 no realiza en ellos la nueva prueba de presencia. La excepción nace del formato, no de una regla general según la cual faltar equivale a permitir. El recibo tiene que conservar la versión y la política que autoriza el tratamiento heredado.

La actualización puede revelar incompatibilidades. Una CA pudo emitir un certificado v3 destinado a firmar CRL pero omitir keyUsage. Los programas antiguos aceptan sus listas; los actualizados las rechazan. La firma no ha dejado de ser correcta: se ha empezado a exigir el mandato que el perfil ya pretendía.

Por eso RFC 10007 recomienda que las CA incluyan la extensión en esos certificados. Si el perfil no se puede cambiar, la autoridad que gestiona la política PKI debería exigir DN diferentes para certificados de finalidades diferentes. La separación de nombres reduce la ambigüedad, pero no modifica certificados ya emitidos ni decide la caducidad de una excepción.

Llamar «regresión» a todo rechazo borra la deuda descubierta. Llamar «incidente de seguridad» a todo perfil defectuoso inventa hechos. La conclusión correcta identifica el requisito ausente y deja abierta la investigación sobre explotación e impacto.

Autorizar al firmante no valida toda la CRL

La comprobación cRLSign ocupa una etapa. Aún hay que seleccionar el emisor correcto, construir la ruta, verificar firma y algoritmo, interpretar los puntos de distribución y el issuing distribution point, tratar CRL indirectas y extensiones críticas, y decidir si thisUpdate y nextUpdate hacen que la información sea vigente.

Las CRL completas y delta deben combinarse con su relación correcta. Después se busca el número de serie del certificado objetivo y, si aparece, la fecha y razón de revocación. Una lista firmada por una clave autorizada puede estar vencida, fuera de ámbito o indicar que el objetivo está revocado.

El resultado positivo de una etapa no llena las demás. Tampoco un rechazo por autorización demuestra que la lista sea falsa o que una clave haya sido robada. Describe que la credencial seleccionada no representa el permiso requerido.

La lente de agency de Heng Lu distribuye bien el trabajo. Los autores fijan una gramática común. La CA diseña el perfil. El proveedor implementa el validador. La autoridad de política aprueba excepciones y la aplicación decide qué hacer con un resultado indeterminado. Ninguno puede prestar su autoridad sin dejar rastro.

La especificación mínima sincroniza el significado del control. Las decisiones de despliegue permanecen locales. El running code muestra qué ocurrió realmente, siempre que se registren las entradas y no solo un estado final.

Reconstruir la decisión, no solo conservar el color

El recibo identifica el certificado objetivo, el ancla, la URI y el hash de la CRL, la hora de descarga, thisUpdate, nextUpdate, el algoritmo y la versión del software. Para el certificado emisor guarda número de serie, Subject Key Identifier, Authority Key Identifier relevante, DN y versión.

Luego registra por separado ruta, firma, condición v3, presencia y criticality de keyUsage, y cRLSign. Una excepción v1/v2 incluye política, responsable, población, vencimiento y revisor.

Otro bloque conserva el ámbito: distribution point, cRLIssuer, estado indirecto, issuing distribution point, razones cubiertas y relación completa/delta. El último bloque contiene la búsqueda del serial objetivo, fecha y razón, evidencia vencida o ausente y decisión de la aplicación.

Con esa estructura, dos flotas que discrepan aportan información. Puede faltar la nueva prueba, variar el certificado elegido o fallar la vigencia. Un único «CRL rejected» no permite distinguirlo.

La afirmación final no necesita excederse: un validador identificado procesó una CRL exacta con un certificado v3 concreto; encontró keyUsage y cRLSign; produjo resultados independientes para ruta, firma, ámbito, vigencia y serial. La seguridad mejora cuando cada test conserva su jurisdicción.

Fuentes