El panorama de los estándares

Spec Spec: ISO 32000-2 ISO 32000-2 Spec Spec: ETSI EN 319 142-1 ETSI EN 319 142-1 Spec Spec: RFC 3161 RFC 3161 Spec Spec: WCAG 2.2 WCAG 2.2 Evidence § Standard-backed Evidence: Standard-backed

De un vistazo

Un motor PDF no responde a un único documento, sino a una pequeña federación de documentos redactados por organismos distintos y referenciados entre sí. Esta página es el mapa de esa federación tal como la sigue NextPDF. También describe el camino que recorre una cláusula desde «un estándar lo dice» hasta «el motor lo hace y una prueba lo demuestra».

Está pensada para un ingeniero sénior que necesita saber qué documento rige un comportamiento antes de decidir si la interpretación de NextPDF es defendible.

Por qué esto importa

«Compatibilidad con PDF» es una afirmación que esconde una pregunta: ¿compatibilidad con qué, exactamente? La sintaxis del núcleo es ISO 32000-2. Las firmas pasan por ETSI. Las marcas de tiempo son un protocolo de la IETF. El HTML y el CSS que el motor representa pertenecen al W3C. La criptografía subyacente corresponde al NIST. La accesibilidad de la salida vuelve al W3C.

Si una biblioteca trata todo eso como un único bloque indiferenciado, no es posible razonar sobre un fallo. Cuando un validador rechaza una factura firmada, la primera pregunta útil no es «¿está roto el PDF?». Es «¿qué cláusula de qué estándar no se cumplió y por cuál de las partes?». Para plantear esa pregunta se necesita un mapa que nombre los organismos y una descripción honesta de cómo una cláusula se convierte en comportamiento.

La versión breve

• NextPDF sigue cinco organismos de estandarización. ISO rige el formato. ETSI rige los perfiles de firma europeos. IETF rige los protocolos de transmisión (marcas de tiempo, primitivas criptográficas por referencia). W3C rige HTML, CSS y los criterios de accesibilidad. NIST rige los algoritmos criptográficos aprobados.
• Estos documentos forman rutas, no una lista: una única capacidad de PDF firmado recorre ISO → ETSI → IETF → NIST, y cada capa referencia normativamente a la siguiente.
• Una cláusula no se convierte en comportamiento solo por leerse. Se convierte en comportamiento al ser parafraseada y citada, asignada a un requisito, implementada y fijada mediante una prueba. La página que describe el comportamiento lo indica con su nivel de evidencia.
• Cuando una cláusula es obligatoria, usa una palabra clave normativa (un shall, un must). NextPDF trata esas palabras clave como contrato. Un should es una recomendación que NextPDF documenta como tal, no como una garantía.

Cómo lo aborda NextPDF

La federación, no un bloque único

ISO 32000-2 es el centro. Define qué es un archivo conforme. Un archivo conforme debe cumplir todos los requisitos del documento y, al mismo tiempo, puede omitir cualquier característica que el documento no exija explícitamente Spec Spec: ISO 32000-2, §6 ISO 32000-2 §6 . También impone una obligación a quien escribe: todo lo que NextPDF crea o modifica en un archivo debe ajustarse al formato y mantenerse coherente con los elementos ya presentes Spec Spec: ISO 32000-2, §6 ISO 32000-2 §6 . Esa sola cláusula es la razón por la que el motor se niega a emitir una actualización incremental estructuralmente incoherente. No es una preferencia de NextPDF. Es la regla propia del formato.

Desde ese centro, ISO 32000-2 apunta hacia fuera. Su tratamiento de las firmas se define «por referencia» a la serie ETSI EN 319 142 para PAdES. ETSI, a su vez, referencia la RFC 3161 de la IETF para el token de marca de tiempo y la serie FIPS del NIST para los algoritmos de hash y de firma. Una capacidad es, por tanto, un camino a través de varios documentos, cada uno normativo para su propia capa.

1. Step 1 of 5: ISO 32000-2 §12.8 signatures ISO 32000-2 §12.8 signatures
2. Step 2 of 5: ETSI EN 319 142-1 PAdES baseline ETSI EN 319 142-1 PAdES baseline
3. Step 3 of 5: RFC 3161 timestamp token RFC 3161 timestamp token
4. Step 4 of 5: NIST FIPS 180-4 hash strength NIST FIPS 180-4 hash strength
5. Step 5 of 5: WCAG 2.2 tagged output WCAG 2.2 tagged output

La ruta de estándares que recorre un único PDF firmado validable a largo plazo: ISO define el contenedor y apunta a ETSI para el perfil de firma; ETSI exige una marca de tiempo de la IETF; las primitivas criptográficas están aprobadas por el NIST; la salida representada se somete a la accesibilidad del W3C. Cada flecha es una referencia normativa, no una asociación informal.

Cómo una cláusula se convierte en comportamiento

La forma peligrosa de trabajar con estándares consiste en leer una cláusula y luego escribir código a partir de lo que se recuerda de ella. El camino de NextPDF es deliberadamente más largo, porque ese es el camino que se puede auditar:

1. Retrieve The clause is read from the standard, not from memory.
2. Cite It is paraphrased and pinned with a chunk digest, never quoted.
3. Classify Its keyword (shall / should / may) sets whether it is a contract or a recommendation.
4. Map The obligation becomes a concrete engine requirement.
5. Implement The requirement is built into the pipeline.
6. Pin A test holds the behaviour against drift.
7. Tag The page that describes it declares its evidence level.

El camino desde una cláusula normativa hasta un comportamiento del motor verificado mediante pruebas: recuperar y citar la cláusula, clasificar su obligación según su palabra clave normativa, asignarla a un requisito del motor, implementarla, fijarla con una prueba y etiquetar la página que la documenta con su base de evidencia. Una cláusula que se detiene antes de la prueba es una afirmación, no un comportamiento.

El paso de «clasificar» es donde se resuelve la mayor parte de la ambigüedad. Las especificaciones codifican sus niveles de requisito en palabras clave: la conocida familia MUST, SHALL, SHOULD, MAY. El significado de esas palabras clave lo fija la convención de la IETF sobre palabras clave de requisito, actualizada para aclarar que solo las formas en mayúsculas son normativas, y luego se superpone a la prosa descriptiva de cada especificación Spec Spec: RFC 2119 RFC 2119 Spec Spec: RFC 8174 RFC 8174 . NextPDF lee un shall como un límite estricto que el motor no traspasa, y un should como una recomendación que sigue y documenta como recomendación — nunca como una promesa. Esa distinción es la diferencia entre una declaración honesta de capacidades y una afirmación excesiva.

La conformidad es graduada, no binaria

«Conforme» rara vez es un único bit. Los estándares de firma están escalonados: el perfil europeo de largo plazo con archivado, por ejemplo, existe precisamente para añadir tokens de marca de tiempo que mantienen una firma validable mucho después de haber sido creada Spec Spec: ETSI EN 319 122-1, §6 ETSI EN 319 122-1 §6 . Esto es una afirmación estrictamente más fuerte que una simple firma de nivel base. El estándar de accesibilidad sigue la misma lógica: un nivel de conformidad solo se alcanza satisfaciendo todos los criterios de éxito de ese nivel, y una declaración indica el nivel que realmente se alcanzó Spec Spec: WCAG 2.2, §5.2.1 WCAG 2.2 §5.2.1 . NextPDF declara, por tanto, el perfil y el nivel, no un «conforme» sin matizar.

Human-factors note: Human-factors note

La ruta de estándares se representa como una figura ordenada y con leyenda, no como un gráfico decorativo, porque quien lee debe poder seguir las referencias en secuencia y un lector de pantalla debe anunciarlas en ese mismo orden. Las flechas entre especificaciones son decorativas. El significado lo transmiten por completo los nombres de las especificaciones y la leyenda, que es el equivalente textual de la ruta. Este es el mismo razonamiento que rige todos los diagramas en Insider_: el orden y el significado residen en el marcado, nunca en el color ni en el conector.

Lo que dice la evidencia

Esta página es Evidence § Standard-backed Evidence: Standard-backed : cada afirmación está anclada en una cláusula, parafraseada y citada con un resumen criptográfico para que el siguiente revisor pueda volver a verificarla frente a la fuente.

Capa	Organismo	Cláusula de anclaje (parafraseada)	Qué gobierna en NextPDF
Formato	ISO	Los elementos creados o modificados por quien escribe deben ajustarse y mantenerse coherentes Spec Spec: ISO 32000-2, §6 ISO 32000-2 §6	El PDF que emite el motor
Conformidad	ISO	Un archivo conforme cumple todos los requisitos; las características adicionales son opcionales Spec Spec: ISO 32000-2, §6 ISO 32000-2 §6	Qué significa «salida válida»
Perfil de firma	ETSI	El nivel de largo plazo con archivado añade marcas de tiempo para una validación posterior Spec Spec: ETSI EN 319 122-1, §6 ETSI EN 319 122-1 §6	El perfil PAdES al que apunta una firma
Tiempo de confianza	IETF	Un servicio de marcado de tiempo demuestra que un dato existía antes de un momento determinado Spec Spec: RFC 3161, §2 RFC 3161 §2	El token de marca de tiempo del documento
Criptografía	NIST	Los hashes aprobados difieren en la fortaleza de seguridad que confieren Spec Spec: NIST FIPS 180-4, §1 NIST FIPS 180-4 §1	El algoritmo de resumen bajo una firma
Acceso a la salida	W3C	Un nivel de conformidad exige todos los criterios de ese nivel Spec Spec: WCAG 2.2, §5.2.1 WCAG 2.2 §5.2.1	Las declaraciones de accesibilidad sobre los PDF representados

Los resúmenes citados se registran en el front-matter citations de esta página. Aquí no se reproduce ningún texto de los estándares. La regla que rige esa decisión tiene su propia página. Véase Disciplina de citación.

Ejemplo práctico

El panorama de los estándares no se ejecuta; se lee para decidir qué pedirle al motor. En concreto, una llamada de firma validable a largo plazo declara qué punto de la ruta se necesita:

examples/36-sign-pades-b-b-and-b-t.php

<?php

declare(strict_types=1);

use NextPDF\Core\Document;
use NextPDF\Security\Signature\CertificateInfo;
use NextPDF\Security\Signature\DigitalSigner;
use NextPDF\Security\Signature\SignatureLevel;

// The signature level is a coordinate on the ISO -> ETSI -> RFC trail.
// PAdES B-B is the ETSI baseline CMS SignedData the Core engine produces;
// B-T adds an RFC 3161 timestamp, and B-LT/B-LTA add the DSS and document
// timestamps that keep a signature validatable after the certificate
// expires. The level you name is the point on the trail you are asking for.
$certInfo = CertificateInfo::fromFiles(
    certPath: 'signer-cert.pem',
    keyPath: 'signer-key.pem',
);

// The functional signing path is the direct two-phase signing engine.
// (Document::setSignature() records intent but its writer seam is not yet
// wired and fail-fasts on output — see the PadesOrchestrator docblock.)
$signer = new DigitalSigner(
    certInfo: $certInfo,
    level: SignatureLevel::PAdES_B_B,
);

$result = $signer->sign(file_get_contents('agreement.pdf'));

printf(
    "PAdES %s CMS: %d bytes, timestamp=%s\n",
    SignatureLevel::PAdES_B_B->value,
    $result->getSize(),
    $result->hasTimestamp() ? 'yes' : 'no',
);

Nombrar PAdES_B_LTA en lugar de un simple nivel base no es una optimización de rendimiento. Es una decisión sobre hasta qué punto de la ruta de estándares llega la obligación. B-LT y B-LTA incorporan las capas de DSS y de marca de tiempo de archivado, y requieren el paquete LTV enterprise en tiempo de ejecución. En lugar de degradarse de forma silenciosa, el motor se niega a fingir que un nivel inferior entrega uno superior.

Error común

La trampa está en leer «NextPDF cumple los estándares» como una garantía única y absoluta. No lo es, ni lo es en ningún motor honesto. El cumplimiento es por estándar, por cláusula y por nivel. NextPDF apunta a la base de PDF 2.0, a perfiles PAdES nombrados y a niveles de accesibilidad declarados —cada uno acotado, cada uno citado. Una afirmación sin una cláusula y un nivel que la respalden es marketing, e Insider_ no la publica.

La segunda trampa, más sutil, es suponer que un should normativo es una promesa. Es una recomendación. NextPDF documenta las recomendaciones como recomendaciones. Las garantías del motor se construyen a partir de las cláusulas shall, y la diferencia es estructural.

Límites y fronteras

Esta página es el mapa, no el territorio. No enumera todas las cláusulas que NextPDF implementa, ni es un certificado de conformidad. La prueba de cada comportamiento reside en la página temática responsable de ese comportamiento, con el nivel de evidencia propio de esa página —por ejemplo PDF 2.0: qué ha cambiado para el delta del formato.

El panorama de los estándares también se mueve. Se publican nuevas ediciones. Las referencias se reorientan. Una cláusula citada aquí queda fijada a la instantánea del corpus registrada en las citations de esta página. Cuando se revisa un estándar de origen, la cita se vuelve a validar frente a la nueva cláusula, sin asumir que se mantiene. Cuando esta página nombra una capacidad de nivel Premium, lo hace en términos de a qué estándar responde, nunca en términos del mecanismo interno.

Documentación relacionada

• PDF 2.0: qué ha cambiado — el delta concreto de ISO 32000-2 al que apunta la capa de formato de este mapa.
• La documentación como producto — por qué la disciplina de asignar cláusulas a comportamientos se trata como ingeniería.
• Disciplina de citación — la regla que decide cómo se cita aquí una cláusula, y qué significa un nivel de evidencia.

Glosario

• Organismo de estandarización — una organización que publica una especificación (ISO, ETSI, IETF, W3C, NIST). Cada uno rige una capa distinta de la pila de PDF.
• Cláusula normativa — un requisito de un estándar, identificado por su palabra clave (shall/must para lo obligatorio, should para lo recomendado, may para lo opcional).
• Ruta de estándares — una cadena ordenada de especificaciones que recorre una única capacidad, donde cada documento referencia normativamente al siguiente.
• Nivel de conformidad — un escalón graduado de cumplimiento (un perfil base de ETSI, un nivel de WCAG). Una declaración indica el nivel realmente alcanzado, no un «conforme» sin matizar.
• PAdES — PDF Advanced Electronic Signatures, la familia de perfiles de firma ETSI EN 319 142 que ISO 32000-2 referencia para la firma de PDF.