Resumen

  • RFC 3029 permitía que un servicio de validación terminara correctamente y emitiera un Data Validation Certificate firmado cuyo resultado fuera inválido.
  • La respuesta vinculaba solicitud, huella, tiempo, política, estado colectivo y resultados particulares; la aplicación receptora aún debía comprobar su autoridad y decidir su suficiencia.

Un certificado suele presentarse como una credencial positiva. El Data Validation Certificate, DVC, rompía esa intuición. Era el producto firmado de un servidor de validación, no una capa de pintura que volviera correcto al objeto analizado. Podía ser valioso precisamente porque conservaba un resultado negativo con autor, tiempo y reglas identificables.

RFC 3029 formuló la frontera con una frase extraordinariamente clara: DVCSCertInfo aparece tras la ejecución exitosa del servicio, pero ese éxito no implica que la validación haya tenido éxito. Una solicitud puede ser procesable; el servidor puede firmar bien; el documento o certificado puede incumplir la política. Si una interfaz reduce los tres hechos a “operación correcta”, pierde el sentido del protocolo.

Cuatro nombres delimitaban cuatro pruebas

cpd certificaba posesión de datos que habían sido presentados al servidor. ccpd recibía solamente una huella y certificaba la afirmación ligada a ese resumen. El segundo servicio no demostraba que el servidor hubiera visto los bytes originales. La distinción protege contra una inflación frecuente: convertir prueba de un identificador en prueba del objeto identificado.

vsd validaba documentos firmados usando las firmas, certificados, estado y caminos de confianza pertinentes. vpkc validaba uno o varios certificados a un tiempo especificado. El servidor podía consultar CRL, OCSP, directorios u otros servicios, pero el RFC advertía que DVCS no reemplazaba CRL u OCSP para comprobaciones de revocación en entornos abiertos de gran escala.

Los cuatro servicios producían objetos parecidos, aunque respondían preguntas diferentes. Presentar datos, presentar una huella, satisfacer una política de documento firmado y satisfacer una política de certificados no eran sinónimos.

La firma protegía una respuesta con estructura

El DVC usaba CMS SignedData. Dentro permanecían visibles la información de solicitud, la huella del material, un número de serie creciente, el tiempo de respuesta, la política, el resultado colectivo y, cuando correspondía, el detalle de cada certificado o firma. Si el tiempo procedía de un servicio externo, el DVCS tenía que validarlo antes de usarlo.

Por eso el cliente no podía detenerse al comprobar la firma exterior. Debía verificar tiempo aceptable, identidad del DVCS, referencia a la solicitud, huella, firma, estado, servicio y política, además del certificado con el que el servidor firmó. Una respuesta auténtica para otra huella o bajo una política inaceptable seguía sin servir para la decisión presente.

La política señalaba el alcance del veredicto. Un servidor podía confiar en una raíz que otro rechazaba, exigir dos firmas donde otro exigía tres o usar información de estado distinta. El DVC decía “este servidor concluyó esto bajo estas reglas”, no “el objeto es válido para cualquier actor y propósito”.

El resumen no sustituía los elementos

En un conjunto de certificados, un fallo colectivo podía originarse en un solo elemento. Los detalles permitían encontrarlo. En un documento con varias firmas, el fallo de una firma no tenía que invalidar todo el documento si la política consideraba suficiente a las demás; el resultado podía ser grantedWithMods. También ocurría lo contrario: firmas individualmente correctas no satisfacían necesariamente un requisito global. granted quedaba reservado a la verificación satisfactoria de todas las firmas.

La etiqueta colectiva era una conclusión de política, no una suma mecánica. WAITING tampoco era una aprobación débil: indicaba que faltaba una respuesta final y que su continuación dependía de la política del servicio.

No era lo mismo negar que no poder responder con autoridad

Un DVC firmado podía afirmar que el objeto no había superado la validación. Si la solicitud no se podía ejecutar por formato o autenticación, el servidor emitía una notificación de error. El primer caso resolvía la pregunta de fondo en sentido negativo; el segundo no llegaba a resolverla.

Cuando el propio DVCS no podía producir una firma válida—por ejemplo, si sabía comprometida su clave—RFC 3029 preveía una estructura sin información de firmante. El cliente debía tratarla como error crítico y fatal, sin confiar implícitamente en el texto. Un dictamen negativo firmado es evidencia autenticada. Un error sin firma es una ruptura de la autoridad de respuesta.

RFC 3029 se publicó en febrero de 2001 como Experimental, no como estándar de Internet. RFC 3379 y RFC 5055 desarrollaron después requisitos y un protocolo distintos para validación delegada. Ese linaje no prueba implantación del DVCS. Sí muestra una preocupación duradera: externalizar el cálculo no elimina la obligación de conservar qué se preguntó, qué política se aplicó y quién tomó la decisión final.

Sources

Lu Heng no redactó ni respaldó RFC 3029 ni las normas PKIX relacionadas. Sus ensayos se usan aquí como marcos analíticos declarados.