Dos implementaciones que dicen "cumplimos RFC 5280" pueden llegar a resultados distintos frente a la misma ruta de certificación, y ninguna de las dos está incumpliendo el estándar. Esto pasa porque el RFC define tres mecanismos separados —perfil del certificado, algoritmo de validación de ruta y verificación de CRL— y solo uno de ellos tiene piso obligatorio estricto. Los otros dos dejan margen explícito de MAY.
Esta nota separa esas tres capas usando el texto del RFC, sin asumir cómo las implementa cada librería o verificador real.
Capa 1: Certificate Policies es un dato en el certificado, no un proceso
La sección 4.2.1.4 de RFC 5280 define la extensión Certificate Policies dentro del perfil del certificado X.509v3, en el mismo bloque donde están Policy Mappings (4.2.1.5) y Policy Constraints (4.2.1.11). Es información que viaja en el certificado: un conjunto de OIDs que declaran bajo qué política se emitió.
Esa extensión, por sí sola, no valida nada. Es un dato disponible para que otro proceso lo use o lo ignore. El propio índice del documento muestra la separación estructural:
4.2.1.4. Certificate Policies ......................32
4.2.1.5. Policy Mappings ...........................35
4.2.1.11. Policy Constraints .......................43
...
6.1. Basic Path Validation .....................72
6.3. CRL Validation .............................90
El perfil de certificado (sección 4) y la validación de ruta (sección 6) son secciones distintas del RFC. Que un certificado tenga Certificate Policies no implica que el verificador vaya a leerlas ni a exigirlas.
Capa 2: el algoritmo de path validation define un mínimo, no un máximo
La sección 6.1 describe el algoritmo básico de validación de ruta de certificación. El RFC es explícito sobre su alcance:
"Thus, the path validation algorithm presented in Section 6.1 defines the minimum conditions for a path to be considered valid."
Es un piso. Cualquier implementación puede ampliar ese piso, y el RFC lo dice con la misma palabra que usa para marcar lo opcional: MAY.
"An implementation MAY augment the algorithm presented in Section 6.1 to further limit the set of valid certification paths that begin with a particular trust anchor."
Los ejemplos que da el propio texto: aplicar una restricción de longitud de ruta a un trust anchor específico, exigir una forma particular de nombre alternativo en el certificado destino, o imponer requisitos sobre extensiones específicas de la aplicación. Y hay un caso puntual que conecta directo con la capa 1: un trust anchor puede limitarse a confiar en rutas asociadas a una política de certificado particular.
"...a trusted CA may only be trusted for a particular certificate policy. This restriction can be expressed through the inputs to the path validation procedure."
Es decir: las Certificate Policies de la capa 1 solo importan si el algoritmo de la capa 2 las recibe como input y decide usarlas. Una implementación puede correr el algoritmo básico de la sección 6.1, ignorar por completo esos inputs adicionales, y seguir siendo conforme al RFC. El texto es igual de claro sobre trust anchors autofirmados: pueden llevar una extensión de policy constraints indicando que las rutas que arrancan ahí solo deben confiarse para políticas específicas, pero el algoritmo básico "no asume que esa información esté presente" y "no especifica reglas de procesamiento" para ella. Procesarla o ignorarla queda a discreción de cada implementación.
Capa 3: CRL checking es, literalmente, opcional de implementar como algoritmo
La sección 6.3 describe cómo determinar si un certificado está revocado cuando el mecanismo de revocación es una CRL. Acá el RFC no dice MAY, dice algo más fuerte todavía:
"Conforming implementations that support CRLs are not required to implement this algorithm, but they MUST be functionally equivalent to the external behavior resulting from this procedure when processing CRLs that are issued in conformance with this profile."
No hace falta implementar el algoritmo detallado paso a paso. Alcanza con producir el mismo resultado externo. Esto es una libertad de implementación amplia: dos verificadores pueden llegar a la misma conclusión de revocado/no-revocado por caminos internos completamente distintos, y ambos son conformes.
Hay además un detalle operativo que el RFC marca y que una implementación básica puede pasar por alto: cuando la CA firma certificados y CRLs con claves privadas distintas, verificar la revocación exige construir y validar una segunda ruta de certificación completa, separada, para el certificado que firma la CRL.
"CRL checking in turn requires a separate certification path to be constructed and validated for the CA's CRL signature validation certificate."
El RFC incluso ajusta el nivel de obligatoriedad según el escenario:
"Applications that perform CRL checking MUST support certification path validation when certificates and CRLs are digitally signed with the same CA private key. These applications SHOULD support certification path validation when certificates and CRLs are digitally signed with different CA private keys."
Con la misma clave, es MUST. Con claves separadas, baja a SHOULD. Una implementación que solo cubre el caso de clave compartida no está violando el RFC: está cubriendo el MUST y dejando afuera el SHOULD.
Las tres capas en conjunto
flowchart TD
A[Certificado X.509v3] -->|contiene| B[Certificate Policies OIDs<br/>seccion 4.2.1.4]
A --> C[Algoritmo de path validation<br/>seccion 6.1 - piso minimo]
B -.->|input opcional MAY| C
C --> D{Verificador soporta CRL?}
D -->|si| E[CRL Validation<br/>seccion 6.3 - algoritmo no obligatorio]
D -->|no| F[Ruta valida sin chequeo de revocacion]
E --> G{Misma clave CA/CRL?}
G -->|si, MUST| H[Path validation exigido]
G -->|no, SHOULD| I[Path validation recomendado, no obligatorio]El diagrama muestra dónde está el margen: la flecha punteada entre Certificate Policies y el algoritmo de la sección 6.1 es un input opcional, no un enlace automático. Un certificado puede declarar una política y esa declaración nunca llegar a influir en el resultado de la validación, porque depende de que el verificador la pida como input.
Por qué esto importa para interoperabilidad
Dos verificadores pueden aceptar como válida exactamente la misma ruta de certificación, aunque uno de ellos ignore las Certificate Policies del certificado y no chequee revocación, mientras el otro aplique restricciones de política adicionales y CRL checking completo con path validation para la clave de firma de CRL. Ninguno de los dos incumple RFC 5280: el primero cubrió el mínimo de la sección 6.1; el segundo, MAY adicionales que el RFC permite pero no exige.
Esto es una lectura editorial, no un hallazgo textual del RFC: el documento no habla de interoperabilidad legal ni de firma digital con validez jurídica. Pero la estructura normativa —piso obligatorio angosto, extensiones opcionales anchas— explica por qué "conforme a RFC 5280" es una condición necesaria y no suficiente para que dos sistemas de verificación lleguen al mismo veredicto sobre una firma.
Límites de esta lectura
El fragmento de RFC 5280 disponible para esta nota está truncado y no cubre el detalle completo de los pasos de inicialización de la sección 6.1 ni el algoritmo de policy mapping paso a paso. Tampoco hay acá datos sobre qué hacen en la práctica navegadores, librerías TLS o motores de firma electrónica concretos: el RFC describe el estándar, no el comportamiento de software real, y no hay evidencia en este documento sobre cuántas implementaciones activan o no cada capa opcional.
El texto tampoco menciona OCSP ni otros mecanismos de revocación modernos — todo lo dicho sobre "no obligatoriedad del algoritmo" aplica específicamente a CRL, sección 6.3, y no se puede extender sin evidencia adicional a otros protocolos de revocación.
Fuente original: https://www.rfc-editor.org/rfc/rfc5280
Este artículo fue publicado originalmente en juanchi.dev
Top comments (0)