Stage 5c in the README and the changelog

The README says that stage 5 is done and the library evaluates the whole
security area as Go, and has the section of part 5c: securitycms.dart,
the order of its checks, the validity of a certificate at the time of
its seal, the round time and Go's zero time, what the reader throws, the
default evaluator and what is exported. It describes the new vectors and
how the generator makes them, and gives the times of opening the two
fixtures with certificates and seals. The changelog has the entry of the
part, with its tests and its injected faults.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

CHANGELOG.md

@@ -4,6 +4,34 @@ Cambios notables de la librería Dart. El proyecto usa versionado semántico; mi
 
 ## Especificación 0.11, en la rama `v0.11` — sin versión
 
+### Etapa 5c: la firma de `alg` 2 y el sello de `seal_type` 2 en los veredictos (06-10-2026)
+
+- **Los veredictos de la firma con certificados y del sello RFC 3161** (`lib/src/securitycms.dart`), port de `evaluateCMS`, `signerLine` y `evaluateSeal` de `signature2.go` de `datekeys-go` en `c531e93`, el borrador v0.12, sobre el lector de CMS de la 5a, con el mismo orden de comprobaciones:
+  - `SIGNERS` con su perfil, de 1 a 16 entradas en orden estricto, y después la `SignedData`: un fallo de cualquiera de los dos es F1;
+  - cada firmante exigido, en el orden de `SIGNERS`, y cada ajeno, en el orden de la codificación, con su resultado: válido, inválido, ausente, no verificable, sin sello, con el sello inválido o con el certificado fuera de validez en t, el instante de su sello, con los dos extremos incluidos;
+  - F2 si un exigido es inválido, F5 si falta algo o hay una clave 3, y F6 si todos son válidos y están sellados, con el `Detail` de los firmantes;
+  - el sello sobre `SEAL_SUBJECT`: S2 por la forma, S1 por un algoritmo fuera de la tabla o un `messageImprint` que no es SHA-256, S3 si no verifica, y S4 o S5 con la autoridad y t;
+  - un `round_time` en el instante cero de Go, 0001-01-01T00:00:00Z, cuenta como ninguno, como `IsZero`, y `Verdicts.sealedAt` no cuenta un sello en ese instante, como `SealedAt`.
+- **El evaluador por defecto lo evalúa todo como Go.** `cmsReader` es el `cms` por defecto de `evaluateSecurity`, y con él el de `evaluateSecurityInput` y de la apertura: nada que Go evalúe queda sin evaluar. Con `cms: null`, la firma de `alg` 2 y el sello de `seal_type` 2 siguen quedando sin evaluar.
+- **`lib/datekeys.dart`** exporta `encodeSigners` y `maxSigners`, como `EncodeSigners` y `MaxSigners` del paquete `capsule` de Go, y `cmsReader`. `cms.dart` sigue interno.
+- **Vectores de Go:** `tool/security_go_vectors.go` escribe además `securitycms_vectors.json`: 760 áreas cuya firma CMS o sello RFC 3161 hace el propio generador, como los hace `internal/cms/cmstest` para las pruebas de la referencia, con los veredictos de `EvaluateSecurityIn`, las líneas, el detalle de cada firmante y del sello y el sello más temprano:
+  - un firmante exigido de cada resultado junto a ajenos de cada resultado, sin `round_time`, al abrir en el instante de los sellos, en el contexto de otro head y con una clave 3; tres firmantes exigidos, sacados de una semilla; `SIGNERS` de 16 y 17 entradas;
+  - la validez de un certificado en el instante de su sello, al nanosegundo, de un `UTCTime` a un `GeneralizedTime` y con diez cifras de fracción, y la de la autoridad en el de su token;
+  - t más la precisión frente a `round_time`, a un nanosegundo de cada lado, con cada forma de la precisión, en el instante cero de Go y en el último segundo de 9999;
+  - un sello de cada veredicto junto a una firma de cada veredicto, y mutaciones de la `SignedData`, de `SIGNERS` y de los tokens.
+
+  `cmstest` no se puede importar desde fuera del árbol de `datekeys-go`: el generador reescribe la parte que necesita. Las claves salen de etiquetas, ECDSA firma con el nonce del RFC 6979 y RSA con PKCS #1 v1.5, así que el fichero sale igual en cada ejecución, y `security_vectors.json` sale como antes. `securitycms_vectors.g.dart` lleva, para Node.js, una parte de los casos, con cada par de veredictos de cada grupo, y los fixtures `format3_signed_cms` y `format3_sealed`.
+- **Pruebas.** Todo se compara con Go:
+  - los 135 casos de `security_cms.json`, con el resultado de cada firmante, el sello y las líneas, sin ningún carácter de control ni bidireccional;
+  - los 24 de `security.json`, ya enteros;
+  - las 56 firmas de `alg` 2 y los 105 sellos de `seal_type` 2 de `security_vectors.json` que la 5b dejaba sin evaluar;
+  - los 760 casos de `securitycms_vectors.json`, con su detalle y su sello más temprano;
+  - y los fixtures `format3_signed_cms` y `format3_sealed`: su área frente a su registro, y su apertura con cada credencial de `open_cases.json`.
+
+  En Node.js corren una parte de los vectores y la apertura entera de los dos fixtures. 150 pruebas nuevas en la VM y 10 en Node.js: 1572 y 332 en total.
+- **Fallos inyectados**, uno a uno y revertidos: los ocho del encargo, el primero en dos formas, y tres más. Las pruebas los detectan todos, en la VM y en Node.js: un certificado comprobado con el reloj de la apertura, y otro en `round_time`, en lugar de en el instante de su sello; un sello aceptado con t más la precisión después de `round_time`; F6 sin que todos los firmantes sean válidos; más de 16 firmantes aceptados; el aviso de los sellos ausente de las líneas de F6; un nombre de 65 puntos de código mostrado; un `messageImprint` que no es SHA-256 aceptado; el resultado de un firmante ajeno en inglés; los firmantes ajenos en el orden inverso; un sello de la clave 3 comprobado sin el `SIG_PART` de la clave 2; y una clave 3 junto a una firma de `alg` 2 ignorada. Dos se escapaban al principio en Node.js, más de 16 firmantes y el orden de los ajenos, porque sus casos solo los leían las pruebas de la VM: la parte de Node.js lleva ahora `SIGNERS` de 16 y 17 entradas y dos firmantes ajenos.
+- **`tool/open_bench.dart`** abre también los dos fixtures y mide, dentro de cada apertura, la evaluación de su área de seguridad: en la VM, una apertura tarda unos 55 ms, de los que el área son 9,4 ms con la firma de dos firmantes sellados y 8,5 ms con la de `alg` 1 y el sello; compilada a JavaScript, unos 0,9 s, de los que el área son 0,13 y 0,05 s. Las cifras, en el README.
+
 ### Etapa 5a: el lector de CMS, ECDSA y RSA (05-10-2026)
 
 - **El lector de las firmas CMS y de los sellos RFC 3161** (`lib/src/cms.dart`), port de `internal/cms` de `datekeys-go` en `c531e93`, con el perfil de certificado del borrador v0.12 (§29.7, §29.10, §29.11), el mismo orden de comprobaciones y los textos de Go:

README.md

@@ -6,7 +6,7 @@ Es la tercera implementación de la especificación, después de la de referenci
 
 ## Estado
 
-Están hechas las etapas 0 a 4 del plan (`docs/PLAN_dart.md` del espacio de trabajo) y las partes 5a y 5b de la etapa 5:
+Están hechas las etapas 0 a 5 del plan (`docs/PLAN_dart.md` del espacio de trabajo):
 - la etapa 0, el paquete, sus herramientas y `testdata/` sincronizado;
 - la etapa 1, los errores normativos, los bytes, el perfil CBOR del §58 y el DER estricto, también el de los tiempos;
 - la etapa 2, las primitivas y la lectura de `age`;
@@ -15,12 +15,14 @@ Están hechas las etapas 0 a 4 del plan (`docs/PLAN_dart.md` del espacio de trab
   - la 4a, las reglas de rutas y de textos con las tablas de Unicode 18.0.0, y la llave de palabras;
   - la 4b, los formatos de la cápsula y de la llave de acceso: las tramas, `PUBLIC_HEADER`, `CONTROL_CBOR` de los tres formatos, la `.dkk`, las extensiones, el Provider Profile, la DateKey con sus rondas y el relleno;
   - la 4c, el head del formato 3, la nota pública, la inspección (pasos 1 a 8) y la apertura (pasos 9 a 18) de los tres formatos;
-- la parte 5b de la etapa 5: los compromisos de lo que firma un autor y sella un sello, `SECURITY_CBOR`, la firma de `alg` 1 y los veredictos con sus textos y sus líneas;
+- la etapa 5, en tres partes:
-- la parte 5a de la etapa 5: el lector de las firmas CMS y de los sellos RFC 3161 con el perfil de certificado del borrador v0.12, ECDSA y RSA. Es interno, y la parte 5c lo une a los veredictos.
+  - la 5b, los compromisos de lo que firma un autor y sella un sello, `SECURITY_CBOR`, la firma de `alg` 1 y los veredictos con sus textos y sus líneas;
+  - la 5a, el lector de las firmas CMS y de los sellos RFC 3161 con el perfil de certificado del borrador v0.12, ECDSA y RSA. Es interno;
+  - la 5c, la firma de `alg` 2 y el sello de `seal_type` 2 en los veredictos, que une el lector de la 5a a la evaluación de la 5b.
 
-La librería ya abre cápsulas reales, de los tres formatos, con todas sus credenciales, y evalúa su área de seguridad como Go: la firma de `alg` 1 y todos los veredictos de su forma. La firma de `alg` 2 y el sello de `seal_type` 2 necesitan el lector de CMS: hasta la parte 5c quedan sin evaluar, nunca con un veredicto supuesto.
+La librería ya abre cápsulas reales, de los tres formatos, con todas sus credenciales, y evalúa toda su área de seguridad como Go: la firma de `alg` 1, la de `alg` 2 con certificados, el sello de `seal_type` 2 y todos los veredictos de su forma.
 
-Las etapas 2 y 3 se hicieron en paralelo, en ramas aparte desde la etapa 1, y se integraron el 5 de octubre de 2026. Las partes 4a y 4b también: la 4a, en la rama `stage4a`, se integró encima de la 4b el mismo día. La 4c se hizo después, en la rama `v0.11`, y la 5b también, en paralelo con la 5a, el lector de CMS, que se hizo en la rama `stage5a` y se integró encima de la 5b el mismo día.
+Las etapas 2 y 3 se hicieron en paralelo, en ramas aparte desde la etapa 1, y se integraron el 5 de octubre de 2026. Las partes 4a y 4b también: la 4a, en la rama `stage4a`, se integró encima de la 4b el mismo día. La 4c se hizo después, en la rama `v0.11`, y la 5b también, en paralelo con la 5a, el lector de CMS, que se hizo en la rama `stage5a` y se integró encima de la 5b el mismo día. La 5c, que necesitaba las dos, se hizo después, en la rama `v0.11`.
 
 La etapa 1 porta tres ficheros de `datekeys-go` en `601e6d2`, con las mismas lecturas, las mismas comprobaciones en el mismo orden y los mismos textos de error:
 
@@ -155,7 +157,7 @@ Notas de la parte 5b:
   - `evaluateSignature(signers, value, hasSeal, context)` da null, que es F1, o F2, F5 o F6 con el `Detail` de los firmantes, como `evaluateCMS` de Go;
   - `evaluateSeal(token, signature, context)` da de S1 a S5, y con S4 y S5 la autoridad y t, como `evaluateSeal` de Go.
 
-  `evaluateSecurity` lo recibe en `cms`. Sin él, la firma de `alg` 2 y el sello de `seal_type` 2 en un contexto quedan en null, sin evaluar, y la otra parte se evalúa igual: `Verdicts.evaluated` es falso y las líneas son las de la otra parte. Lo que lance el lector, o un veredicto fuera de su rango, es F1 o S2. La 5c lo implementará en `securitycms.dart` y lo pondrá en `evaluateSecurityInput`; `holderText` ya está aquí para ella.
+  `evaluateSecurity` lo recibe en `cms`. Sin él, la firma de `alg` 2 y el sello de `seal_type` 2 en un contexto quedan en null, sin evaluar, y la otra parte se evalúa igual: `Verdicts.evaluated` es falso y las líneas son las de la otra parte. Lo que lance el lector, o un veredicto fuera de su rango, es F1 o S2. La 5c lo implementa en `securitycms.dart`, `cmsReader`, que es desde entonces el `cms` por defecto; `holderText` estaba ya aquí para ella.
 - **Las líneas** son las de Go, byte a byte: los nombres de un certificado entre « y », la autoridad de cada sello en las de F6 con su aviso, los resultados en español y t en RFC 3339 con la fracción del sello. Partir cada línea en filas con `  ↳ ` (§29.7) es de la CLI de Go (`cmd/datekeys/present.go`), no del paquete `capsule`: no se porta, y lo hará la app en una salida de texto.
 - **El contexto de la apertura** es `newSecurityContext` con el `head_digest`: un control cuyo `CONTROL_SIG` no se puede codificar deja `control_commit` a cero, como en Go, y la firma no verifica.
 - **`authorCode`** toma los bytes del mensaje como Go toma los de un string: un byte que no es UTF-8 se lee como U+FFFD.
@@ -179,6 +181,20 @@ Notas de la parte 5a:
 - **Los vectores** salen de la rama `v0.12` de Go en `c531e93`, en una exportación suya. La 5a se hizo con `testdata/` todavía en `spec-v0.11`, así que toma del `security_cms.json` y de los fixtures del borrador lo que necesita a través de su generador, de la exportación.
 - **Interno**, como `internal/cms`: `lib/datekeys.dart` no lo exporta.
 
+La parte 5c de la etapa 5 porta `signature2.go` de `datekeys-go` en `c531e93`, el borrador v0.12: une el lector de CMS de la 5a a la evaluación de la 5b, con el mismo orden de comprobaciones, los mismos veredictos, el mismo resultado de cada firmante y el mismo detalle, que las líneas de la 5b escriben como Go:
+
+| Módulo | Contenido | En Go |
+|---|---|---|
+| `lib/src/securitycms.dart` | `cmsReader`, el `CmsEvaluator` por defecto: la firma de `alg` 2 (`SIGNERS`, la `SignedData`, la línea de cada firmante exigido y de cada ajeno, y F2, F5 o F6 con su detalle) y el sello de `seal_type` 2 (de S1 a S5, con la autoridad y t); `encodeSigners` y `maxSigners` | `evaluateCMS`, `signerLine`, `evaluateSeal`, `EncodeSigners` y `MaxSigners` de `signature2.go` |
+
+Notas de la parte 5c:
+- **El orden de las comprobaciones** es el de Go y el del §29.10: `SIGNERS`, con su perfil y como mucho 16 entradas, antes que la `SignedData`, y un fallo de cualquiera de los dos es F1. Después, cada firmante exigido, en el orden de `SIGNERS`, y cada ajeno, en el orden de la codificación, con su resultado: no verificable, inválido, sin sello, con el sello inválido, fuera de validez o válido. El sello de un firmante es su token, leído con el perfil del §29.11 sobre el valor de su firma: S2, S1 o S3 es un sello inválido, y su `messageImprint` puede usar cualquier hash de la tabla. F2 va antes que F5, y una clave 3 junto a una firma de `alg` 2 es F5.
+- **La validez de un certificado** se comprueba en t, el instante de su sello, con los dos extremos incluidos y al nanosegundo (§29.10, paso 6), como `ValidAt(tok.GenTime)` de Go: ni en `round_time` ni en el reloj de la apertura. La de la autoridad, en `genTime`, la comprueba el lector de la 5a.
+- **Antes de la fecha de apertura** quiere decir t más la precisión estrictamente antes de `round_time`. Sin `round_time` ningún sello es anterior, y un `round_time` en el instante cero de Go, 0001-01-01T00:00:00Z, cuenta como ninguno, como `IsZero` en Go. `Verdicts.sealedAt` tampoco cuenta un sello en ese instante, como `SealedAt`; su línea lo muestra igual.
+- **Lo que lanza el lector de CMS** con una firma o un token que incumple su perfil, una `CmsException`, es un veredicto: F1, un sello inválido, S2 o S1. Cualquier otra cosa llega a `evaluateSecurity`, que la hace un fallo de su parte, F1 o S2, como Go recupera un panic.
+- **El evaluador por defecto.** `cmsReader` es el `cms` por defecto de `evaluateSecurity`, y con él el de `evaluateSecurityInput` y de la apertura: nada que Go evalúe queda sin evaluar. Con `cms: null` la firma de `alg` 2 y el sello de `seal_type` 2 quedan en null, para quien no quiera pagar su coste, por ejemplo en la web (ver «Rendimiento»).
+- **Lo que se exporta** es lo del paquete `capsule` de Go: `encodeSigners` y `maxSigners`, y `cmsReader`. `cms.dart` sigue interno.
+
 Los enteros son exactos en la VM y en la web. El `int` de Dart tiene 64 bits con signo en la VM y en la web es un double, exacto hasta 2^53. Por eso la librería no usa un `int` por encima de 2^53-1, ni desplazamientos u operaciones de bits de más de 31 bits:
 - un entero de CBOR es un `int` hasta 2^53-1 y un `BigInt` por encima, como el `number | bigint` de `datekeys-ts`;
 - `CborDecoder.uint` devuelve un `int`, porque todos los esquemas acotan sus enteros en 2^53-1, y `uint64` devuelve un `BigInt`;
@@ -199,7 +215,6 @@ Las etapas siguientes traen el resto del protocolo en este orden:
 
 | Etapa | Contenido |
 |---|---|
-| 5 | La parte 5c: la firma de `alg` 2 y el sello de `seal_type` 2 sobre el lector de CMS de la 5a, unidos a los veredictos de la 5b en el evaluador de la apertura |
 | 6 | Escritor |
 | 7 | Localizador y claves de autor |
 
@@ -307,10 +322,12 @@ Cada apertura verifica su release: entre dos, la de otro release hace que cada u
 | Abrir `format2_time_and_key_recipients` con su `.dkk`, 16 stanzas | 73 ms | 0,82 s |
 | Abrir `format3_single`, un fichero | 52 ms | 0,81 s |
 | Abrir `format3_time_and_key_portable` con su `.dkk` | 72 ms | 0,82 s |
+| Abrir `format3_signed_cms`, una firma de `alg` 2 de dos firmantes, cada uno con su sello | 55 ms, de ellos el área de seguridad 9,4 ms | 0,95 s, de ellos el área 0,13 s |
+| Abrir `format3_sealed`, una firma de `alg` 1 y un sello de `seal_type` 2 | 55 ms, de ellos el área 8,5 ms | 0,89 s, de ellos el área 0,05 s |
 | 64 MiB en el formato 1, en streaming | 1,50 s, 43 MiB/s | 16 MiB: 0,73 s, 22 MiB/s |
 | 64 MiB en un fichero del formato 3, en streaming | 2,64 s, 24 MiB/s | 16 MiB: 0,92 s, 17 MiB/s |
 
-Una apertura pequeña es casi toda los pasos 10 y 11, la verificación del release y el IBE. En una grande manda ChaCha20-Poly1305, unos 21 ms por MiB en la VM; en el formato 3 se suma el SHA-256 de cada fichero, otros 17 ms por MiB, el de este código como el de `package:crypto`. La memoria no crece con el tamaño: la fuente se lee por tramos de 1 MiB y el texto llega al sink chunk a chunk.
+Una apertura pequeña es casi toda los pasos 10 y 11, la verificación del release y el IBE. El área de seguridad de las dos cápsulas con certificados la evalúa el evaluador por defecto, con el lector de CMS, y su tiempo se mide dentro de la apertura; sus dos filas son del 6 de octubre. En `format3_signed_cms` son cuatro verificaciones, la ECDSA de P-256 de Ana, la RSA-2048 de Luis y las ECDSA de P-256 de sus dos sellos; en `format3_sealed`, la de Ed25519 de la firma de `alg` 1 y la de P-256 del sello. En Node.js manda la ECDSA sobre el `BigInt` compilado a JavaScript (ver «ECDSA, RSA y CMS»). En una grande manda ChaCha20-Poly1305, unos 21 ms por MiB en la VM; en el formato 3 se suma el SHA-256 de cada fichero, otros 17 ms por MiB, el de este código como el de `package:crypto`. La memoria no crece con el tamaño: la fuente se lee por tramos de 1 MiB y el texto llega al sink chunk a chunk.
 
 ### ECDSA, RSA y CMS
 
@@ -390,7 +407,7 @@ dart run tool/sync_testdata.dart check --against ../datekeys-go
 - Los ficheros de `testdata/` no se editan ni se generan aquí.
 - En cada `dart test`, `test/testdata_test.dart` comprueba la copia, y que cada fichero nombre `specVersion`.
 
-`test/vectors/` tiene los vectores de las primitivas, de `age`, de BLS12-381, de tlock, de las reglas de rutas y textos, de la llave de palabras, de los formatos, de la apertura, del área de seguridad y del lector de CMS. Los escribe Go, con las librerías de la caché de módulos que usa `datekeys-go` (`x/crypto`, `filippo.io/age`, `kilic/bls12-381`, `drand/kyber`, `kyber-bls12381` y `tlock`) y sus paquetes, como `provider`, `agewrap`, `capsule`, `internal/pathrule`, `internal/testkit` y `wordkey`; ningún valor esperado se escribe a mano. Los generadores van en `tool/`, con `//go:build ignore`, y se ejecutan en el contexto del módulo de `datekeys-go`, sin cambiar nada en él; los de las rutas, de la apertura y del lector de CMS, en una exportación suya, y el último, `tool/cms_go_vectors_test.go`, como una prueba de Go. Los de BLS12-381 y tlock dan la misma salida con el tag `spec-v0.11` y con el borrador v0.12, y leen ficheros congelados de `datekeys-ts`, cuya carpeta en esta máquina se llama todavía `App`:
+`test/vectors/` tiene los vectores de las primitivas, de `age`, de BLS12-381, de tlock, de las reglas de rutas y textos, de la llave de palabras, de los formatos, de la apertura, del área de seguridad, de la firma con certificados y el sello, y del lector de CMS. Los escribe Go, con las librerías de la caché de módulos que usa `datekeys-go` (`x/crypto`, `filippo.io/age`, `kilic/bls12-381`, `drand/kyber`, `kyber-bls12381` y `tlock`) y sus paquetes, como `provider`, `agewrap`, `capsule`, `internal/pathrule`, `internal/testkit` y `wordkey`; ningún valor esperado se escribe a mano. Los generadores van en `tool/`, con `//go:build ignore`, y se ejecutan en el contexto del módulo de `datekeys-go`, sin cambiar nada en él; los de las rutas, de la apertura y del lector de CMS, en una exportación suya, y el último, `tool/cms_go_vectors_test.go`, como una prueba de Go. Los de BLS12-381 y tlock dan la misma salida con el tag `spec-v0.11` y con el borrador v0.12, y leen ficheros congelados de `datekeys-ts`, cuya carpeta en esta máquina se llama todavía `App`:
 
 ```bash
 cd ../datekeys-go && go run ../datekeys-dart/tool/gen_primitive_vectors.go -out ../datekeys-dart/test/vectors
@@ -432,7 +449,7 @@ cd ../datekeys-go && go run ../datekeys-dart/tool/mutation_go_texts.go ../dateke
 cd ../datekeys-go && go run ../datekeys-dart/tool/security_go_vectors.go -testdata ../datekeys-dart/testdata -out ../datekeys-dart/test/vectors
 ```
 
-`holderText` no se exporta en el paquete `capsule`: `tool/security_go_vectors.go` llega a él con `go:linkname`, que Go permite con un paquete de fuera de la biblioteca estándar.
+`holderText` no se exporta en el paquete `capsule`: `tool/security_go_vectors.go` llega a él con `go:linkname`, que Go permite con un paquete de fuera de la biblioteca estándar. El mismo programa escribe los vectores de la parte 5c, `securitycms_vectors.json`, con firmas CMS y tokens RFC 3161 que hace él mismo como los hace `internal/cms/cmstest` para las pruebas de la referencia: ese paquete no se puede importar desde fuera del árbol de `datekeys-go`, así que el generador reescribe la parte que necesita. Las claves salen de etiquetas, ECDSA firma con el nonce del RFC 6979 y RSA con PKCS #1 v1.5, así que la salida no depende de `crypto/rand`.
 
 `internal/pathrule` solo se puede importar desde el árbol de `datekeys-go`, así que el generador de las rutas corre en una exportación suya, hecha con `git archive`, sin tocar el repositorio:
 
@@ -494,6 +511,8 @@ rm -rf "$tmp"
 | `open_vectors.g.dart` | Siete fixtures pequeños, lo que sus registros dicen de ellos y una parte de los cuatro ficheros `open_*.json`, como constantes de Dart |
 | `security_vectors.json` | El área de seguridad del paquete `capsule`: los compromisos, también `ControlCommit` del control de cada fixture en cada formato; los codificadores; 1730 evaluaciones con `EvaluateSecurityIn` en 23 contextos y sin contexto, del mapa exterior, de `author-signature` y de `seal` rotos de todas las formas de sus esquemas y en sus límites, de firmas de `alg` 1 válidas e inválidas, guardadas o no, con los casos de «Taming the many EdDSAs» hechos sobre `AUTHOR_MESSAGE`, y de mutaciones de una semilla fija, con los veredictos, las líneas, `alg` y `seal_type` leídos y las partes que solo evalúa el lector de CMS; las líneas y el sello más temprano de veredictos con cada detalle; y `holderText` |
 | `security_vectors.g.dart` | Todo `security_vectors.json` salvo siete de cada ocho evaluaciones, como constante de Dart |
+| `securitycms_vectors.json` | La firma de `alg` 2 y el sello de `seal_type` 2 como los evalúa `EvaluateSecurityIn`: 760 áreas que hace el generador, con los veredictos, las líneas, el detalle de cada firmante y del sello y el sello más temprano. Un firmante exigido de cada resultado junto a ajenos de cada resultado, sin `round_time`, al abrir en el instante de los sellos, en el contexto de otro head y con una clave 3; tres firmantes exigidos sacados de una semilla; `SIGNERS` de 16 y 17 entradas; la validez de un certificado en el instante de su sello, al nanosegundo, de un `UTCTime` a un `GeneralizedTime` y con diez cifras de fracción, y la de la autoridad; t más la precisión frente a `round_time` a un nanosegundo de cada lado, con cada forma de la precisión, en el instante cero de Go y en el último segundo de 9999; un sello de cada veredicto junto a una firma de cada veredicto; y mutaciones de la `SignedData`, de `SIGNERS` y de los tokens. Los certificados, los tokens y los `SignerInfo` que se repiten van una vez, como trozos |
+| `securitycms_vectors.g.dart` | Una parte de `securitycms_vectors.json`, con cada par de veredictos de cada grupo, y los fixtures `format3_signed_cms` y `format3_sealed` con lo que dicen sus registros, como constantes de Dart |
 | `cms_ecdsa.json` | Las curvas de `crypto/elliptic`; puntos que lee o no `ecdsa.ParseUncompressedPublicKey`; y firmas de `ecdsa.VerifyASN1`: válidas, con s por encima de n/2, r o s de n o más, cero, negativas o no mínimas, en otra codificación, sobre otro hash, y con claves de d = 1 y d = n − 1, con u1·G + u2·Q en el infinito |
 | `cms_rsa.json` | Claves de 2048, 2049, 3072, 4095 y 4096 bits con los exponentes 3, 65 537 y 2³¹ − 1, y firmas de `rsa.VerifyPKCS1v15` y `rsa.VerifyPSS` como las comprueba `internal/cms`: válidas, con un byte más o menos, de n o más, y codificaciones hechas a mano y firmadas con la clave privada, cada una con un defecto de su relleno |
 | `cms_certs.json` | `cms.ParseCert`, sus campos, `Holder`, `IssuerName` y `ValidAt` alrededor de los dos extremos, en los certificados de las pruebas de `internal/cms`, en identificadores cuyo último arco da la vuelta en 32 o 64 bits, y en certificados editados nodo a nodo y bit a bit |
@@ -504,11 +523,11 @@ rm -rf "$tmp"
 | `cms_vectors.g.dart` | Una parte de cada fichero `cms_*.json`, como constantes de Dart |
 
 - Los fixtures que leen los generadores son los de `testdata/` de este repositorio, la copia sincronizada.
-- `primitives.json`, los cuatro ficheros de BLS12-381 y tlock, `pathrule_vectors.json`, `wordkey_vectors.json`, los de los formatos, `security_vectors.json` y los del lector de CMS salen iguales en cada ejecución, estos últimos con Go 1.26.8. Lo aleatorio de tlock, los ciphertexts de kyber con su sigma y los de `datekeys-ts`, se lee de los ficheros congelados de `datekeys-ts` en `289fe71`, y Go los descifra otra vez. `age`, en cambio, saca sus claves y nonces de `crypto/rand`, así que `age.json` y `age_fixtures.json` cambian en cada ejecución; las pruebas leen lo que esté en el repositorio. `age.json` no lee `testdata/` y es el congelado de la etapa 2; `age_fixtures.json` se escribió otra vez con el `testdata/` de la v0.12, y fuera de los dos fixtures nuevos y del de `seal_type` 4294967295 sale igual.
+- `primitives.json`, los cuatro ficheros de BLS12-381 y tlock, `pathrule_vectors.json`, `wordkey_vectors.json`, los de los formatos, `security_vectors.json`, `securitycms_vectors.json` y los del lector de CMS salen iguales en cada ejecución, estos últimos con Go 1.26.8. Lo aleatorio de tlock, los ciphertexts de kyber con su sigma y los de `datekeys-ts`, se lee de los ficheros congelados de `datekeys-ts` en `289fe71`, y Go los descifra otra vez. `age`, en cambio, saca sus claves y nonces de `crypto/rand`, así que `age.json` y `age_fixtures.json` cambian en cada ejecución; las pruebas leen lo que esté en el repositorio. `age.json` no lee `testdata/` y es el congelado de la etapa 2; `age_fixtures.json` se escribió otra vez con el `testdata/` de la v0.12, y fuera de los dos fixtures nuevos y del de `seal_type` 4294967295 sale igual.
 - Un fichero `age` de más de un chunk se guarda como su cabecera, su nonce y su file key: la prueba cifra otra vez el texto documentado y comprueba el SHA-256 del fichero entero antes de leerlo. Las cabeceras de megabytes se escriben como partes que se repiten.
 - Los casos de `open_cases.json` que editan un fixture lo sellan otra vez como el `testkit` de la referencia, con las file keys y los nonces del fixture, así que salen iguales en cada ejecución, y se guardan como ediciones del fixture.
-- Los ficheros del lector de CMS escriben una vez por fichero los certificados que se repiten: el DER de un caso es entonces una lista de trozos, el hexadecimal de unos bytes o el índice de un certificado, con el SHA-256 del resultado.
+- Los ficheros del lector de CMS escriben una vez por fichero los certificados que se repiten: el DER de un caso es entonces una lista de trozos, el hexadecimal de unos bytes o el índice de un certificado, con el SHA-256 del resultado. `securitycms_vectors.json` hace lo mismo con los certificados, los tokens y los `SignerInfo`, cada trozo hecho a su vez de los anteriores, y una mutación se guarda como su base, el objetivo de la edición (la `SignedData`, `SIGNERS` o el token) y la edición.
-- Las pruebas que corren en Node.js no leen ficheros. Los valores de Go que usan están en `primitives.g.dart`, `pathrule_vectors.g.dart`, `wordkey_vectors.g.dart`, `formats_vectors.g.dart`, `open_vectors.g.dart`, `security_vectors.g.dart`, `cms_vectors.g.dart`, `test/bls12381_constants.dart` y `test/ibe_constants.dart`. Unas pruebas en la VM comparan con los JSON los de las rutas, la llave de palabras, los formatos, la apertura, el área de seguridad, el lector de CMS, BLS12-381 y el IBE.
+- Las pruebas que corren en Node.js no leen ficheros. Los valores de Go que usan están en `primitives.g.dart`, `pathrule_vectors.g.dart`, `wordkey_vectors.g.dart`, `formats_vectors.g.dart`, `open_vectors.g.dart`, `security_vectors.g.dart`, `securitycms_vectors.g.dart`, `cms_vectors.g.dart`, `test/bls12381_constants.dart` y `test/ibe_constants.dart`. Unas pruebas en la VM comparan con los JSON los de las rutas, la llave de palabras, los formatos, la apertura, el área de seguridad, la firma con certificados y el sello, el lector de CMS, BLS12-381 y el IBE, y con `testdata/` los fixtures que llevan.
 
 ## Licencia