Resumen

  • La revisión 07, fechada el 2 de noviembre, añade una frase que faltaba en la 06: si el cliente rechaza una cadena por un motivo distinto de la confianza en su raíz, SHOULD NOT elegir el identificador de esa ancla para reintentar.
  • El texto menciona caducidad, revocación, discrepancia de nombre y restricciones del propio cliente sobre el ancla.
  • La exclusión afecta al identificador de la cadena rechazada. Otra ancla admisible puede permitir la recuperación, con un máximo de un reintento por conexión.

Una llave conocida no arregla la cerradura rota

Piense en entrar al portal de pagos de una empresa. El navegador conoce a la autoridad que firmó la cadena, pero el certificado muestra el nombre de otro sitio. La conexión debe fallar por identidad. Volver a pedir la misma ancla como si la firma resolviera el nombre sería darle una segunda oportunidad al documento equivocado.

El mecanismo propuesto permite a un servidor ofrecer varias rutas de certificación y anunciar sus identificadores de ancla en EncryptedExtensions. Un cliente que había pedido anclas adicionales u omitido otras puede, tras un error de conexión o un certificado no confiable, conectar de nuevo al mismo destino solicitando solo una de las anclas ofrecidas. La revisión del 2 de noviembre conserva esa salida, pero añade un filtro. La versión del 30 de septiembre describía la recuperación sin él.

La diferencia se juega después de validar la primera cadena. Si llega a una raíz reconocida, pero falla porque el certificado venció, fue revocado, identifica otro nombre o viola una restricción local sobre esa raíz, el cliente no debería escoger el ID asociado a esa misma cadena para su segunda petición. El verbo normativo es SHOULD NOT. No prohíbe todos los reintentos ni convierte una raíz conocida en garantía sobre el resto del camino.

El servidor puede ofrecer otro ID; el cliente lo elige según el orden anunciado y sus preferencias. Sin extensión o sin coincidencia, devuelve el error a la aplicación. El registro de la IETF mantiene el documento como borrador de grupo de trabajo, I-D Exists. No consta en las fuentes examinadas una aceptación indebida de certificados causada por este mecanismo. El cambio acota una decisión de diseño antes de que la señal de confianza en la raíz se confunda con aprobación del certificado presentado.