Resumen

  • En el ejemplo de RFC 5217, PKI2 pertenece a dos dominios. Eso permite construir una ruta desde PKI1 hasta PKI3, pero la validación bajo la política del dominio 1 no debe prosperar porque los extremos no comparten ese dominio.
  • Los certificados cruzados aportan conectividad firmada. La aceptación requiere además un ancla de confianza, políticas y restricciones aplicables, estado de pertenencia, información de revocación y una decisión atribuible a la parte que se apoyará en el certificado.

El auditor encontró una ruta y una negativa

La evidencia parecía contradictoria. El motor había recuperado todos los certificados, verificado sus firmas y enlazado el certificado del suscriptor con el ancla configurada. Sin embargo, la decisión final era rechazo. No faltaba material criptográfico; faltaba autorización para usar esa ruta bajo la política solicitada.

RFC 5217 dibuja el problema con tres PKI. PKI2 participa en los dominios 1 y 2. Existe una ruta de PKI1 a PKI2 y otra de PKI2 a PKI3. Por transitividad técnica, el constructor puede llegar desde PKI1 hasta PKI3. Pero PKI1 y PKI3 no comparten el dominio 1. Si la validación se pide con esa política, no debe tener éxito.

La cadena completa demuestra que el grafo está conectado. El rechazo demuestra que la frontera sigue existiendo.

Buscar una cadena no decide el riesgo

La construcción explora certificados hasta encontrar una secuencia que parte de un ancla y termina en una entidad final. La validación evalúa ese candidato: políticas, restricciones, nombres, fechas, uso y revocación. Son fases distintas porque contestan preguntas distintas.

Una arquitectura puente o malla aumenta las rutas posibles. También reduce el número de acuerdos bilaterales necesarios. Ninguna de esas ventajas convierte toda ruta hallada en permiso general.

RFC 5217 mantiene los identificadores de política y la CA principal de cada PKI. Antes de relacionarse, las partes revisan documentos de política y gobierno y deciden qué niveles son comparables. El certificado cruzado formaliza esa conclusión limitada. No fusiona las instituciones ni borra las condiciones que hicieron aceptable la relación.

El miembro doble abre una puerta lateral

El riesgo aparece donde un participante conecta dominios diferentes. Su pertenencia doble puede permitir que un algoritmo encuentre un camino que los extremos nunca acordaron utilizar entre sí. La firma de cada salto no resuelve el problema, porque la pregunta no es sólo quién emitió el certificado, sino para qué comunidad y política se permite confiar en él.

Por eso RFC 5217 lleva la frontera a restricciones firmadas: mapeos de políticas, restricciones de políticas y de nombres. Cuando un dominio necesita limitar una ruta, no debería depender de que cada parte usuaria adivine la misma regla local.

La pertenencia también tiene ciclo de vida. Una PKI que entra o sale de otro dominio cambia el conjunto de rutas alcanzables. Debe notificarlo; los dominios afectados deben revisar sus certificados cruzados y revocarlos y reemitirlos si las restricciones antiguas ya no describen el grafo permitido.

La criptografía protege la declaración. La operación debe comprobar que la declaración aún corresponde a la realidad.

El puente coordina sin convertirse en soberano

El modelo Bridge CA concentra certificaciones cruzadas y reduce su número. RFC 5217, sin embargo, prohíbe usar el puente como ancla de confianza de los dominios participantes. Debe actuar de forma neutral, con su propio identificador de política para los mapeos, y no emitir certificados corrientes a entidades finales.

Esa decisión evita que una utilidad compartida se convierta por comodidad en raíz universal. La parte usuaria continúa partiendo de su ancla. Atravesar el puente exige procesar las condiciones firmadas de cada lado. La centralidad topológica no concede autoridad ilimitada.

La lista de confianza tiene dueño

Una lista local permite a una parte usuaria mantener sus propias anclas, incluso sin certificados cruzados. Es sencilla, pero su actualización queda distribuida. Una Trust Authority administra la lista para varias partes y puede aplicar una política empresarial común.

Centralizar no elimina el juicio. Antes de incluir una PKI hay que revisar su política, el nivel de garantía, las obligaciones para quien confía, las garantías económicas y los avisos de revocación o compromiso. Si la organización no quiere heredar confianza hacia otros miembros del dominio, debe inhibir el mapeo de políticas.

La entrada en la lista cambia qué actos serán aceptados. Añadir una CA puede abrir una capacidad; retirarla puede provocar una denegación de servicio. Por eso la modificación requiere identidad, motivo, fecha, alcance y revisión, no sólo una distribución automática de archivos.

Conservar el recibo de autoridad

Para una decisión importante, guarde más que la cadena. El recibo debe incluir la aplicación que confió, el instante, la versión del validador, la huella y procedencia del ancla, el conjunto de políticas iniciales y los controles de mapeo.

Debe conservar cada certificado del camino, las restricciones procesadas, la foto de pertenencias a dominios, la versión de la lista, la frescura de CRL u OCSP, el resultado final, su razón exacta y la acción posterior. Una cadena construida y rechazada también se conserva: prueba que la política detuvo una ruta que la topología permitía.

Lo que no se afirma

RFC 5217 es informativo y reconoce que existen otras arquitecturas. La misma cadena podría aceptarse con otra ancla, finalidad o comunidad. Este análisis no acusa de fallo a una CA o producto concreto.

La conclusión operativa es más precisa: firma correcta, ruta existente, pertenencia a un dominio y aceptación por una aplicación son hechos diferentes. Si el panel los convierte en un solo estado verde, la interfaz habrá creado una autoridad que el sistema nunca otorgó.

Fuentes

Registro complementario de normas

  1. RFC 5217 en texto plano
  2. Ficha informativa de RFC 5217
  3. Registro de IETF Datatracker
  4. Historial de IETF Datatracker
  5. RFC 4949: glosario de seguridad de Internet
  6. RFC 5914: formato de anclas de confianza
  7. RFC 5934: requisitos de gestión de anclas
  8. RFC 6024: requisitos del protocolo de gestión de anclas
  9. RFC 5055: validación de certificados basada en servidor
  10. RFC 6818: actualizaciones de RFC 5280
  11. RFC 6960: protocolo OCSP
  12. RFC 5019: perfil ligero de OCSP
  13. RFC 6962: transparencia de certificados
  14. RFC 7030: inscripción mediante transporte seguro