Resumen

  • Los clientes nuevos del perfil ligero de RFC 9919 deben usar SHA-256 en los hashes del nombre y la clave del emisor dentro de CertID; los clientes heredados compatibles con RFC 5019 deben abandonar SHA-1 tan pronto como resulte práctico.
  • Durante la transición, un respondedor puede incluir dos SingleResponse, uno con CertID SHA-1 y otro SHA-256. Registrar el algoritmo solicitado puede informar la decisión de retirar la variante antigua.
  • Un registro de origen no cuenta respuestas reutilizadas desde el cliente, un proxy o el servidor, ni las entregadas por stapling, ni necesariamente las que pasan por otra instancia o un acuerdo fuera de banda.
  • SHA-1 en CertID no identifica el algoritmo de firma de la respuesta OCSP: son campos y funciones distintas.
  • El cierre responsable debe unir observación, denominador, excepción, criterio de parada, propietario, canario, vía de reversión, caducidad y verificación posterior.

El contador mide llegada, no dependencia

Un cero en el panel significa que el clasificador no vio solicitudes SHA-1 en la entrada seleccionada durante el intervalo elegido. Convertirlo en “cero clientes heredados” añade dos supuestos que el dato no prueba: que toda la población podía llegar a esa entrada y que cada uso de OCSP generaba una solicitud nueva.

El perfil de alto volumen invalida precisamente el segundo supuesto. Permite respuestas preproducidas y busca minimizar los contactos con el respondedor. El cliente conserva respuestas autoritativas; los proxies HTTP pueden servirlas; el propio servicio puede distribuir objetos preparados. Mediante stapling o piggybacking, la respuesta viaja dentro de otro intercambio y el cliente no abre una sesión HTTP independiente con el servicio OCSP.

Tampoco existe necesariamente una sola entrada. Balanceo geográfico, instancias de respaldo, redes privadas y fallbacks reparten el tráfico. Como OCSP no anuncia en el protocolo las capacidades del respondedor, los operadores pueden definir por acuerdos fuera de banda qué perfil usa un cliente. Esos acuerdos no aparecen por arte de magia en la métrica de una máquina.

Una caída puede reflejar una migración real. También puede reflejar mayor duración de respuesta, mejor caché, más stapling o un cambio de ruta. El dato es útil cuando el recibo conserva esas alternativas, no cuando las borra.

La transición que prescribe la norma

RFC 5019 obligaba a usar SHA-1 en issuerNameHash e issuerKeyHash. RFC 9919 sustituye esa obligación por SHA-256 para los clientes conformes al nuevo perfil. Los clientes antiguos que conservan SHA-1 por compatibilidad tienen una obligación de migración práctica, no una garantía de servicio perpetuo.

El respondedor dispone de un puente. Aunque la forma normal es un solo SingleResponse, puede incluir elementos adicionales por rendimiento de preproducción, eficiencia de caché o compatibilidad. El ejemplo de RFC 9919 empareja una entrada SHA-1 con otra SHA-256. Si ningún cliente necesita ya la primera, el respondedor no debería seguir distribuyéndola. El algoritmo observado en las solicitudes puede ayudar a decidir cuándo ocurre esa situación.

La norma no proporciona, sin embargo, un umbral de tráfico ni una cantidad universal de días sin solicitudes. Tampoco declara que el registro de una instancia sea una encuesta del ecosistema. Esos elementos pertenecen al control operativo local.

La precisión terminológica evita otra falsa conclusión. RFC 6960 define CertID.hashAlgorithm para calcular los hashes del nombre distinguido y de la clave pública del emisor; el número de serie completa la identificación del certificado consultado. BasicOCSPResponse.signatureAlgorithm es independiente. RFC 9919 explica que SHA-1 en este uso de CertID no constituye por sí mismo un problema criptográfico; mantener su compatibilidad obliga a conservar código, complejidad y posible superficie de ataque.

Hacer visible el denominador

El mapa mínimo enumera instancias, hostnames, regiones, rutas, familias de certificados y grupos de clientes. Para cada uno declara si observa solicitud directa, revalidación de caché, entrega por proxy, stapling, uso sin conexión y fallback. “No instrumentado” debe permanecer como estado propio.

El tiempo se vincula a la vida de las respuestas. Si el intervalo es más corto que la respuesta almacenada más longeva, algunos clientes antiguos no tienen motivo para volver a solicitar. Un canario debe cruzar ciclos de renovación y representar los distintos caminos de entrega, no limitarse al certificado más popular.

Los acuerdos fuera de banda y los clientes contractuales se inventarían junto a la telemetría. Si una población no puede medirse, un responsable acepta explícitamente su exclusión y le asigna fecha de revisión. Así, la incertidumbre no se convierte silenciosamente en migración.

Del permiso de cambio al acta terminada

El acta registra alcance, responsable, puntos de observación, denominador, lista de excepciones SHA-1, política de respuesta simple o doble, cobertura de caché y stapling, intervalo y criterio de parada. Define después población y duración del canario, condición de reversión, fallback operativo y caducidad de la excepción.

Tras el corte, añade solicitudes SHA-1 reaparecidas, errores, fallos de validación, uso del fallback, certificados afectados y efecto para el servicio. Ese resultado distingue una retirada completada de una decisión que todavía espera consecuencias.

El IETF fija el comportamiento interoperable; no opera cada flota ni absorbe el impacto comercial. Quien posee el cambio debe poseer también su evidencia. La compatibilidad no se justifica por inercia, pero su final tampoco puede delegarse a un contador sin contexto.

Fuentes