Resumen

  • RFC 9654 admite nonces de 1 a 128 octetos, exige al solicitante moderno un mínimo de 32 y obliga al respondedor compatible a aceptar de 16 a 32; fuera de esa franja puede omitir la extensión.
  • Una coincidencia exacta y aleatoria impide sustituir la respuesta por una copia antigua con otro nonce, pero no demuestra por sí sola que la fuente de revocación esté al día, el firmante sea autorizado o la aplicación deba aceptar el certificado.
  • La prueba operativa debe separar sintaxis, entropía, reflejo, firma, delegación, CertID, tiempos firmados, edad de la fuente, política local y resultado de la sesión.

El máximo no es la promesa

La cifra 128 es atractiva porque parece una recomendación de seguridad: si más longitud ofrece más espacio, usemos el máximo. RFC 9654 no dice eso. Cambia la representación para permitir algoritmos que generan valores mayores de 32 octetos, pero fija obligaciones distintas para quien solicita y quien responde.

El tipo ASN.1 acepta entre uno y 128 octetos. El solicitante que implementa la especificación debe usar al menos 32. El respondedor que soporta la extensión debe aceptar longitudes entre 16 y 32. Para valores de uno a 15 o de 33 a 128, puede responder sin nonce. Cero y más de 128 exigen malformedRequest.

Esta geometría conserva compatibilidad. RFC 8954 había establecido un máximo de 32, de modo que una implementación anterior no puede tratarse como compatible con los nuevos valores largos. Un equipo que elige 128 sin negociar la conducta del servidor ha elegido una posibilidad sintáctica, no un contrato de reflejo.

La extensión tiene dos capas

RFC 9654 coloca el nonce en requestExtensions y, cuando se devuelve, en responseExtensions. El OID común es 1.3.6.1.5.5.7.48.1.2. El extnValue exterior contiene la codificación del Nonce, que es otro OCTET STRING.

La diferencia entre envoltorio y valor es un control real. Un analizador puede localizar el OID y aun comparar bytes equivocados. Puede registrar el contenedor DER en un lado y el contenido en el otro. Puede truncar la representación hexadecimal y declarar igualdad porque sólo compara un prefijo.

Por eso la evidencia mínima conserva el mensaje OCSPRequest completo y su hash, el OCSPResponse completo y su hash, los desplazamientos decodificados, las longitudes exterior e interior y la comparación exacta. Los módulos 111 y 112 que registra IANA coordinan la gramática; no certifican el comportamiento de una biblioteca concreta.

La igualdad sólo vale si el reto era impredecible

RFC 9654 exige que el nonce provenga de un generador pseudoaleatorio criptográficamente fuerte y remite a RFC 4086. Esta condición no es decoración. Si el atacante predice el valor, puede obtener antes una respuesta con ese mismo reto. Si el espacio es demasiado pequeño, puede preparar todas las variantes.

Después, la comparación binaria funcionará. Lo que habrá fallado es la premisa de que el valor nació para esta petición y no era anticipable. La métrica debe cubrir salud del generador, reinicios, repetición entre procesos, longitud efectiva y momento de creación. Un contador de coincidencias no detecta un generador constante.

La especificación inicial mínima de Heng Lu ayuda a situar el requisito: la red comparte formato y comparación determinista; cada operador mantiene visible la fuente de aleatoriedad, la política de despliegue y el riesgo aceptado.

Ligada a la petición no significa nacida de datos actuales

RFC 9654 describe el nonce como enlace criptográfico que evita el replay y hace que la respuesta sea la más reciente del servidor, no una copia antigua. La frase se refiere a la respuesta obtenida del servidor. No garantiza que la base que alimenta al servidor haya recibido el último cambio de la autoridad certificadora.

RFC 6960 mantiene separados producedAt, thisUpdate, nextUpdate y revocationTime. El primero es el momento de firma; el segundo, el momento en que el estado indicado se sabía correcto; el tercero promete información nueva; el cuarto pertenece al hecho de revocación. El CertID identifica emisor y serie.

Considérese una revocación publicada a las 14:00 y un respondedor cuya réplica se actualiza a las 14:07. A las 14:03 puede contestar dinámicamente con el nonce exacto, una firma válida y el estado que conoce. Es una respuesta nueva construida con una vista retrasada. Para demostrar actualidad respecto de la fuente hacen falta el cursor de ingestión, la versión del lote o un recibo equivalente.

La firma abre otra pregunta: ¿pertenece a la CA, a un respondedor confiado directamente o a un delegado autorizado según RFC 6960? La coincidencia del nonce no otorga ese mandato. Y good no prueba que el certificado fuera emitido, esté dentro de validez, corresponda al nombre esperado o autorice la operación solicitada.

La ausencia activa una ruta distinta

El perfil de gran volumen de RFC 5019 favorece respuestas preproducidas y caché. Un nonce por petición reduce esa reutilización. Por ello un servidor puede omitirlo, y un cliente que no conoce soporte explícito no debe rechazar sólo por ausencia; debe recurrir a la validación temporal firmada.

Ese repliegue no debe confundirse con una coincidencia. RFC 9654 reconoce que un atacante en ruta podría devolver una respuesta anterior sin nonce. Acortar el intervalo de thisUpdate a nextUpdate reduce la ventana. El cliente sigue necesitando reloj, política y firma válidos.

Las operaciones deberían distinguir: reflejo exacto; ausencia permitida y repliegue; valor diferente; error de codificación o longitud. También deben registrar qué decisión vino después. Si una actualización cambia silenciosamente la rama, el mismo porcentaje de “éxito OCSP” puede ocultar un control muy distinto.

El recibo completo

La reconstrucción empieza por el certificado objetivo: huella, serie, hashes del emisor y destino OCSP. Añade bytes de petición, versión del generador, instante, longitud y hash protegido del nonce. La respuesta conserva bytes, estado general, identidad del respondedor, cadena, autorización y firma.

Después se guardan presencia e igualdad del nonce, CertID, estado y tiempos. La telemetría de ingestión de la fuente se registra aparte. El cliente añade hora local, incertidumbre, tolerancia, compilación y versión de política. La aplicación cierra con validación de ruta, identidad, admisión o rechazo y efecto sobre la sesión.

Las capas de realidad impiden que una capa simbólicamente fuerte sustituya a las demás. La primacía del código en ejecución exige capturas y decisiones reales, no la inferencia de que una biblioteca “soporta RFC 9654”.

Fuentes