Prompt y contexto
Los nodos de borde de una CDN son numerosos y están expuestos, por lo que distribuir la clave de un certificado de larga duración magnifica el impacto de un compromiso. Usando el RFC 9345, diseña Delegated Credentials (DC): el titular del certificado emite una credencial de corta duración, el borde la utiliza para la autenticación TLS y esta no puede emitir otra DC. Cubre la validación en el handshake, la expiración, la rotación, los límites de revocación y el fallback.
Qué está evaluando el entrevistador
Las señales a evaluar son la comprensión de la vinculación entre una DC y un certificado de entidad final X.509, el límite de autoridad de una clave de corta duración, la negociación de extensiones TLS, las ventanas de tiempo y el impacto de un compromiso. Las respuestas sólidas distinguen la reducción del tiempo de exposición de la revocación instantánea y explican un fallback seguro para clientes sin soporte de DC.
Preguntas clarificadoras para hacer primero
Tráfico y punto de terminación
Confirma si TLS termina en la CDN, en un gateway regional o en el origen, si los bordes abarcan múltiples dominios administrativos y si DTLS o QUIC están involucrados. El punto de terminación determina las rutas de emisión y distribución.
Matriz de compatibilidad de clientes
Identifica las versiones de clientes de navegador, móviles, IoT e internos, y si sus stacks TLS pueden actualizarse. DC requiere negociación de extensiones y una nueva validación, por lo que no se puede asumir soporte.
Objetivo frente a compromisos
Aclara si el objetivo es limitar la exposición de la clave de larga duración, la vida útil de la clave de borde o ambas. Comprueba si el cumplimiento normativo requiere una lista de revocación independiente o un retiro forzado.
Estructura de respuesta en 30 segundos
“El titular del certificado emite una DC de corta duración, cuya firma, uso y vida útil se validan con la clave del certificado de entidad final. Los bordes reciben únicamente la clave privada de la DC y no pueden crear otra DC; los clientes validan la vinculación durante el flujo de extensiones TLS. Se utilizan vidas útiles cortas, rotación superpuesta y aislamiento de claves, mientras se protege la clave de larga duración. Los clientes no compatibles usan una ruta explícita con certificado ordinario; los fallos de validación nunca se degradan silenciosamente. La respuesta ante compromisos se basa en una expiración corta, detener la emisión y, cuando sea necesario, revocar el certificado padre, no en asumir una revocación instantánea de la DC.”
Pasos detallados para la respuesta
Paso 1: Definir la relación de emisión
Un emisor que posee la clave privada de larga duración correspondiente al certificado de entidad final crea la clave pública de la DC, su vida útil, el algoritmo de firma y la información de uso de TLS/DTLS. La clave pública de la entidad final verifica la firma. Los bordes reciben la clave privada de la DC y la credencial pública, nunca la clave privada padre.
Paso 2: Acotar la autoridad y el uso
La clave privada de la DC está limitada al rol acordado de autenticación TLS y no puede emitir otra DC. Valida DelegationUsage, la compatibilidad de algoritmos y el contexto del protocolo para que una credencial exclusiva de TLS no se trate como una clave de firma general.
Paso 3: Validar durante el handshake
El cliente valida la cadena X.509 tradicional, luego la firma de la DC, la vida útil, la vinculación con el padre y el contexto del handshake. Si la negociación de extensiones falla, usa una ruta explícita de certificado ordinario. Los campos de seguridad desconocidos o inconsistentes deben provocar un fallo de validación en lugar de ser ignorados.
Paso 4: Diseñar la ventana de rotación
Establece una superposición para el desvío de reloj del borde, el retraso de propagación y la duración máxima del handshake. Carga la nueva DC antes de alternar mientras la anterior sigue siendo válida; retira la credencial antigua solo después de confirmar la distribución. La sincronización temporal y la monitorización cubren la transición de límite.
Paso 5: Gestionar compromisos y revocación
Un atacante con la clave privada de una DC puede suplantar a la parte en nuevas conexiones hasta que esa DC expire, pero no puede emitir otra DC. La respuesta incluye detener la emisión, acortar las vidas útiles, retirar las credenciales de borde y, si es necesario, revocar el certificado padre o alternar a un certificado ordinario. DC no es un mecanismo de revocación instantánea.
Paso 6: Planificar compatibilidad y fallback
Usa una matriz de clientes y tráfico gradual para verificar el soporte de extensiones. Los clientes no compatibles siguen la ruta de terminación con certificado de larga duración mientras la clave padre permanece aislada. Distingue “el par no tiene soporte” de “falló la validación”; nunca degrades un fallo de validación a texto plano o a un certificado arbitrario.
Paso 7: Observar y ensayar
Registra la emisión, distribución, carga, fallos de handshake, desvío de reloj y tasas de fallback sin registrar claves privadas. Ensaya el compromiso de bordes, la caída del emisor, la revocación del padre y el fallback total para verificar la recuperación dentro del tiempo de vida corto.
Respuesta de ejemplo de alta calidad
Mantendría la clave del certificado de larga duración en un emisor y la usaría para firmar DCs de corta duración; los bordes reciben únicamente la clave privada de cada DC. Durante el handshake, se valida la cadena X.509, luego la vinculación de la DC, el uso, el algoritmo, la vida útil y el contexto del handshake. Rota con superposición, monitoriza relojes, despliega la compatibilidad por fases y proporciona un fallback explícito para clientes antiguos. Si se filtra una DC, detén la emisión, retira las credenciales de borde, espera a que expire y revoca el padre cuando sea necesario. Monitoriza los fallos de validación y las tasas de fallback; DC no ofrece revocación instantánea.
Errores comunes
- Error: Asumir que una DC filtrada puede revocarse instantáneamente como un token de OAuth. → Por qué: El RFC se enfoca en una vida útil corta y en la vinculación con el padre. → Mejora: Acorta la vida útil y prepara la revocación y retiro del certificado padre.
- Error: Permitir que un borde con una clave privada de DC emita más DCs. → Por qué: Esto expande la cadena de delegación y la autoridad. → Mejora: Mantén la clave padre en un emisor controlado.
- Error: Ignorar campos cuando no hay soporte para la extensión. → Por qué: La compatibilidad de negociación no equivale a una validación exitosa. → Mejora: Separa el caso no compatible, el fallo de validación y el fallback ordinario.
- Error: Rotar únicamente según la marca de tiempo de emisión. → Por qué: La propagación y el desvío de reloj pueden hacer que los bordes usen una credencial demasiado pronto o demasiado tarde. → Mejora: Usa superposición y monitoriza la sincronización de tiempo.
Preguntas de seguimiento y respuestas
Pregunta de seguimiento 1: ¿En qué se diferencia una DC de un certificado X.509 ordinario de corta duración?
Una DC está vinculada a un certificado de entidad final existente y se utiliza en el handshake TLS, por lo que el borde no necesita poseer la clave privada padre. Un certificado ordinario de corta duración generalmente aún requiere que la CA o el sistema de certificados emita una cadena completa. Sus límites de despliegue y validación son distintos.
Pregunta de seguimiento 2: ¿Qué puede hacer un atacante con la clave privada de una DC?
Puede suplantar a la parte en nuevas conexiones TLS hasta que la DC expire, pero no puede usarla para emitir otra DC. La ventana de exposición depende de la vida útil, del estado del certificado padre y de la velocidad de detección y respuesta.
Pregunta de seguimiento 3: ¿Por qué es necesario DelegationUsage?
Limita qué certificados permiten explícitamente la participación en DC, reduciendo el riesgo entre protocolos al evitar alimentar una validación de DC con un certificado que no posee semántica de delegación.
Pregunta de seguimiento 4: ¿Requieren QUIC o DTLS una raíz de confianza separada?
No se requiere una nueva raíz de confianza, pero las reglas de extensión y contexto de protocolo del RFC 9345 deben validar el uso, los campos del handshake y los algoritmos. El análisis sintáctico de TLS no puede reutilizarse para otro protocolo sin dicha revisión.