Stage 5a in the README and the changelog

The modules of the CMS reader, ECDSA and RSA, their notes, their
timings, the generator of their vectors and its files; BigInt in ECDSA
and RSA, which only verify with public values; and the entry of stage
5a in the changelog, with its tests and its injected faults.

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

CHANGELOG.md

@@ -4,6 +4,19 @@ 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 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:
+  - `parseCert` lee un certificado campo a campo, sin una librería de X.509; `Cert` da el titular, de `givenName` y `surname` antes que del `commonName`, el emisor, del `organizationName` si no hay un `commonName` con texto, y `validAt`, con los dos extremos incluidos;
+  - `parseSignature` lee una firma separada: el `ContentInfo`, los certificados, las respuestas OCSP, los atributos firmados y sin firmar y cada `SignerInfo`, con su certificado; `SignerInfo.check` da `CmsResult.valid`, `invalid` o `notVerifiable` con la tabla cerrada de algoritmos, y una clave de otro esquema que el algoritmo es `invalid`;
+  - `parseToken` lee un token y su TSTInfo campo a campo, con los errores de forma antes que los de algoritmo, y `Token.check` lo verifica sobre lo sellado: un `messageImprint` de otra longitud no vale, y la precisión llega hasta 2³¹ − 1 segundos;
+  - los identificadores de objeto se comparan por sus bytes, y un SET OF puede repetir un elemento.
+- **ECDSA** (`lib/src/ecdsa.dart`, `nist_curves.dart`) en P-256, P-384 y P-521, como `ecdsa.VerifyASN1` de Go, y **RSA** (`lib/src/rsa.dart`), PKCS #1 v1.5 y PSS como `rsa.VerifyPKCS1v15` y `rsa.VerifyPSS`, de código propio sobre `BigInt`, que no es de tiempo constante: solo verifican, con valores públicos. Los hashes son los de `package:crypto`.
+- **Vectores de Go:** `tool/cms_go_vectors_test.go` corre como una prueba de Go en una exportación de `datekeys-go`, porque importa `internal/cms`, y con `testing/cryptotest` hace deterministas las claves y las firmas. Escribe `cms_ecdsa.json`, `cms_rsa.json`, `cms_certs.json`, `cms_signatures.json`, `cms_algorithms.json`, `cms_tokens.json`, `cms_mutations.json` y `cms_corpus.json`: las pruebas de `internal/cms` con sus resultados y textos, identificadores cuyos arcos dan la vuelta en 32 o 64 bits, certificados, firmas y tokens editados nodo a nodo y bit a bit, y cada firma y cada token de `security_cms.json` y de los fixtures `format3_signed_cms` y `format3_sealed` del borrador v0.12. `cms_vectors.g.dart` lleva una parte de cada uno para Node.js.
+- **Pruebas.** 44 nuevas en la VM y 17 en Node.js. Integrada encima de la 5b, el total es de 1422 pruebas en la VM y 322 en Node.js.
+- **Fallos inyectados**, uno a uno y revertidos: un identificador comparado como texto, un SET OF estrictamente ascendente, el titular tomado primero del `commonName`, una s de ECDSA sin comparar con el orden, el relleno de RSA sin comprobar su longitud (y, aparte, la longitud de la firma), un `messageImprint` de otra longitud aceptado, una precisión de 2³¹ segundos aceptada y un certificado válido un segundo fuera de su periodo. Las pruebas de la VM los detectan todos; las de Node.js, todos menos los de RSA y la precisión, cuyos casos no van en la parte de Node.js.
+- **`tool/cms_bench.dart`** mide ECDSA, RSA y el lector: en la VM, una verificación de P-256 tarda 2,4 ms y una de RSA-2048, 0,10 ms. Las cifras, en el README.
+
 ### Etapa 5b: los compromisos, `SECURITY_CBOR`, la firma de `alg` 1 y los veredictos (05-10-2026)
 
 - **`testdata/` de la rama `v0.12` de `datekeys-go`,** en `c531e93`, cuyo `testdata/` es el de `601e6d2`, el de `datekeys-ts`: 133 ficheros, que dicen aún `"spec": "0.11"`, como el `SpecVersion` de Go, hasta que el autor apruebe el borrador. Frente al tag `spec-v0.11`, trae los fixtures `format3_unsigned` y `format3_note`, `format3_seal_unsupported` con `seal_type` 4294967295, los registros nuevos de `format3_sealed` y `format3_signed_cms`, el corpus de 218 casos, `note.json`, `security.json` con su contexto y sus líneas, `security_cms.json` de 135 casos y `locator.json`, que es de la etapa 7.

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 la parte 5b de la etapa 5:
+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:
 - 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,11 +15,12 @@ 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 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 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 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.
 
-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 va en la rama `stage5a`.
+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 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:
 
@@ -160,6 +161,24 @@ Notas de la parte 5b:
 - **`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.
 - **Lo que se exporta.** `lib/datekeys.dart` exporta `author.dart` y `security.dart` enteros, como el paquete `capsule` de Go; `datekeys-ts` los deja internos.
 
+La parte 5a de la etapa 5 porta `internal/cms` de `datekeys-go` en `c531e93`, la cabeza de la rama `v0.12`, con el perfil de certificado del borrador v0.12 (§29.7, §29.10 y §29.11), y la ECDSA y la RSA de Go que usa, con las mismas lecturas, las mismas comprobaciones en el mismo orden, los mismos resultados y los mismos textos de error:
+
+| Módulo | Contenido | En Go |
+|---|---|---|
+| `lib/src/nist_curves.dart` | P-256, P-384 y P-521 sobre `BigInt`: la lectura de un punto sin comprimir y u1·G + u2·Q en coordenadas jacobianas, con el truco de Shamir | `ecdsa.ParseUncompressedPublicKey`, `crypto/internal/fips140/nistec` |
+| `lib/src/ecdsa.dart` | `verifyEcdsaAsn1`: la firma leída como la lee `cryptobyte`, r y s entre 1 y n − 1 sin reducirlos, una s por encima de n/2 aceptada y el hash cortado a los bits del orden | `ecdsa.VerifyASN1` |
+| `lib/src/rsa.dart` | `verifyPkcs1v15`, que construye la codificación y la compara entera, y `verifyPss`, con MGF1 y una sal de la longitud del hash; `Sha2`, los hashes de la tabla, con el `DigestInfo` de cada uno | `rsa.VerifyPKCS1v15`, `rsa.VerifyPSS` |
+| `lib/src/cms.dart` | `parseCert` con el perfil del §29.10, campo a campo, y `Cert` con `holder`, `issuerName` y `validAt`; `parseSignature`, `SignedData` y `SignerInfo` con `check`, que da un `CmsResult`; `parseToken` y `Token` con `check`; `addDuration`, t más la precisión; y los errores: `CmsFormException`, `CmsAlgorithmException` y `CertificateException` | `internal/cms` |
+
+Notas de la parte 5a:
+- **Lo que trae.** El lector de la firma de `alg` 2 y del sello de `seal_type` 2. Los compromisos, `SECURITY_CBOR`, la firma de `alg` 1 y los veredictos con sus textos son de la parte 5b, y la unión de este lector con los veredictos, de la 5c: `evaluateCMS` y `evaluateSeal`, con la línea de cada firmante.
+- **Los nombres** siguen a los de Go, para importar el módulo con prefijo (`import 'cms.dart' as cms;`): `ErrForm` y `ErrAlgorithm` son `CmsFormException` y `CmsAlgorithmException`, las dos de la clase sellada `CmsException`, y el `Result` de Go es `CmsResult`, porque `CheckResult` ya es de la inspección. Cada error lleva el texto de `err.Error()` de Go.
+- **El perfil del certificado.** Los identificadores de objeto se comparan por los bytes de su DER, así que un arco de 2^64 + 3 no es el 3 de nadie; un SET OF puede repetir un elemento; el titular sale de `givenName` y `surname` si los dos tienen texto no vacío, antes que del `commonName`; el emisor, del `commonName` o, si no tiene uno con texto, del `organizationName`. Como Go, y no como `datekeys-ts`, `parseCert` no comprueba antes que los bytes sean DER: dentro de una firma siempre lo son.
+- **Las curvas** son las tres de la tabla del §29.10, P-521 incluida, porque Go la acepta. Las claves RSA miden de 2048 a 4096 bits, con un módulo impar y un exponente impar de 3 a 2³¹ − 1; una clave de otro esquema que el algoritmo da `invalid`, como en Go.
+- **Los tiempos** son `Instant`, al nanosegundo. La precisión de un token es una `Duration`: como mucho 2³¹ − 1 segundos, 999 milisegundos y 999 microsegundos, cuyos microsegundos quedan por debajo de 2^53, exactos en la web. `addDuration` da t más la precisión, lo que el §29.7 compara con `round_time`.
+- **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.
+
 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`;
@@ -167,17 +186,20 @@ Los enteros son exactos en la VM y en la web. El `int` de Dart tiene 64 bits con
 - Poly1305 guarda el acumulador y r en diez limbs de 13 bits: cada producto queda por debajo de 2^31 y cada suma por debajo de 2^35, y sus acarreos se toman con `~/`, no con un desplazamiento, que en la web truncaría a 32 bits;
 - el cuerpo de curve25519 es el de TweetNaCl en su versión de JavaScript: dieciséis limbs de 16 bits en un `Float64List`, con sumas de productos por debajo de 2^44;
 - en BLS12-381 los elementos del cuerpo y los escalares son `BigInt`, y una ronda es un `int` hasta 2^53-1, cuyos 8 bytes se escriben como dos mitades de 32 bits;
-- en las tablas de Unicode, la clase de combinación de un punto de código va en una entrada que vale el punto por 256 más la clase, por debajo de 2^29, así que sus desplazamientos quedan en 32 bits.
+- en las tablas de Unicode, la clase de combinación de un punto de código va en una entrada que vale el punto por 256 más la clase, por debajo de 2^29, así que sus desplazamientos quedan en 32 bits;
+- en ECDSA y RSA los enteros grandes son `BigInt`; las longitudes de DER, los INTEGER pequeños y el exponente de RSA son un `int` de cuatro bytes como mucho, por debajo de 2^32, que se lee sin desplazamientos.
 
 **`BigInt` no es de tiempo constante.** En las primitivas se usa solo con datos públicos: la reducción de escalares módulo ℓ y las comprobaciones de `onCurve` en Ed25519, que solo verifica, y el factor de trabajo de un stanza scrypt. Los secretos de las primitivas (el escalar de X25519, las claves de HMAC, ChaCha20 y Poly1305) van en la aritmética de limbs, sin ramas ni índices que dependan de ellos; ni la VM ni un motor de JavaScript prometen tiempo constante, aun así.
 
+ECDSA y RSA hacen con `BigInt` toda su aritmética, y solo verifican: la clave de un certificado, la firma y el mensaje son públicos. La librería no firma con ninguno de los dos.
+
 BLS12-381, en cambio, hace con `BigInt` toda su aritmética. Verificar un release y descifrar un stanza tlock solo manejan datos públicos: la firma de la ronda lo es desde que drand la publica, y el stanza va en la cápsula. Cifrar no: sigma y r son secretos, y el tiempo del código depende de ellos. El escritor (etapa 6) cifrará el stanza tlock donde ese tiempo no se pueda observar, o con una capa del cuerpo de limbs fijos sin ramas que dependan de los datos.
 
 Las etapas siguientes traen el resto del protocolo en este orden:
 
 | Etapa | Contenido |
 |---|---|
-| 5 | El lector de CMS, en la parte 5a, y en la 5c la firma de `alg` 2 y el sello de `seal_type` 2 sobre él |
+| 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 |
 
@@ -290,6 +312,34 @@ Cada apertura verifica su release: entre dos, la de otro release hace que cada u
 
 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.
 
+### ECDSA, RSA y CMS
+
+`dart run tool/cms_bench.dart` mide ECDSA, RSA y el lector de CMS en la VM. Compilado a JavaScript:
+
+```bash
+dart compile js -O2 -o cms_bench.js tool/cms_bench.dart
+```
+
+```bash
+node cms_bench.js
+```
+
+Son medianas de tres ejecuciones, el 5 de octubre de 2026:
+
+| Operación | VM | Node.js |
+|---|---|---|
+| ECDSA P-256 con SHA-256, una verificación | 2,4 ms | 32 ms |
+| ECDSA P-384 con SHA-384, una verificación | 5,6 ms | 96 ms |
+| ECDSA P-521 con SHA-512, una verificación | 12 ms | 235 ms |
+| RSA de 2048 bits, PKCS #1 v1.5 o PSS, una verificación | 0,10 ms | 5,1 ms |
+| RSA de 3072 bits, una verificación | 0,17 ms | 9,1 ms |
+| RSA de 4096 bits, una verificación | 0,29 ms | 17 ms |
+| `parseCert` de un certificado de 337 bytes (P-256) o de 739 (RSA-2048) | 0,01 a 0,02 ms | 0,02 ms |
+| `parseSignature` y `check` de una cofirma de ECDSA y RSA | 3,6 ms | 36 ms |
+| `parseToken` y `check` de un token de ECDSA P-256 | 2,6 ms | 30 ms |
+
+Manda ECDSA: con el exponente 65 537, una verificación de RSA son 17 multiplicaciones modulares, y una de ECDSA en P-256, unos 256 dobles de punto y 190 sumas. Una firma de dos firmantes con sus sellos son cuatro verificaciones: unos 10 ms en la VM y 0,13 s en Node.js con P-256.
+
 ## Versiones
 
 | Número | Dónde | Hoy |
@@ -301,7 +351,7 @@ La rama sigue la versión de la especificación: `v0.11`, hasta que `datekeys-go
 
 ## Dependencias
 
-- **En ejecución:** solo `package:crypto`, para SHA-1, SHA-2 y HMAC. Todo lo demás es código propio: HKDF, PBKDF2, scrypt, ChaCha20-Poly1305, X25519, Ed25519, BLS12-381, ECDSA, RSA, DER, CMS y CBOR. Hoy la librería usa de `package:crypto` SHA-512, en Ed25519, y SHA-256, en BLS12-381 y tlock. Las primitivas tienen además su propio SHA-256 con HMAC-SHA256, porque PBKDF2 los necesita con los estados de la clave calculados una vez.
+- **En ejecución:** solo `package:crypto`, para SHA-1, SHA-2 y HMAC. Todo lo demás es código propio: HKDF, PBKDF2, scrypt, ChaCha20-Poly1305, X25519, Ed25519, BLS12-381, ECDSA, RSA, DER, CMS y CBOR. Hoy la librería usa de `package:crypto` SHA-512, en Ed25519, SHA-256, en BLS12-381 y tlock, y SHA-1, SHA-256, SHA-384 y SHA-512, en CMS. Las primitivas tienen además su propio SHA-256 con HMAC-SHA256, porque PBKDF2 los necesita con los estados de la clave calculados una vez.
 - **En desarrollo:** solo `package:test`, aprobado el 5 de octubre de 2026. No hay paquete de lints: las reglas del análisis están en `analysis_options.yaml`.
 - **`pubspec.lock`** va en el repositorio, para que las pruebas usen siempre las mismas versiones.
 
@@ -340,7 +390,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 y del área de seguridad. 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 y de la apertura, en una exportación suya. 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 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
@@ -396,7 +446,20 @@ cp tool/pathrule_go_vectors.go "$tmp"
 rm -rf "$tmp"
 ```
 
-El de la apertura también, porque usa `internal/testkit`, `internal/cbortest` e `internal/inspectview`:
+El de la apertura también, porque usa `internal/testkit`, `internal/cbortest` e `internal/inspectview`. El del lector de CMS, que importa `internal/cms` y `internal/cms/cmstest`, corre además como una prueba de Go, para que `testing/cryptotest.SetGlobalRandom` haga deterministas las claves y las firmas:
+
+```bash
+commit=$(git -C ../datekeys-go rev-parse v0.12)
+out=$PWD/test/vectors
+tmp=$(mktemp -d)
+git -C ../datekeys-go archive "$commit" | tar -x -C "$tmp"
+mkdir "$tmp/cmsvectors"
+cp tool/cms_go_vectors_test.go "$tmp/cmsvectors/"
+(cd "$tmp/cmsvectors" && go test -run TestWriteVectors -count=1 -args -source "$commit" -out "$out")
+rm -rf "$tmp"
+```
+
+La exportación para la apertura:
 
 ```bash
 commit=$(git -C ../datekeys-go rev-parse v0.12)
@@ -431,12 +494,21 @@ 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 |
+| `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 |
+| `cms_signatures.json`, `cms_algorithms.json` | `cms.ParseSignature` y `SignerInfo.Check` en las firmas de las pruebas de `internal/cms` (la forma, los algoritmos y las claves), con identificadores que dan la vuelta y SET OF con un elemento repetido |
+| `cms_tokens.json` | `cms.ParseToken` y `Token.Check` en los tokens de esas pruebas, el TSTInfo campo a campo, la precisión y el `messageImprint` en sus límites, y la autoridad en los extremos de su validez, al nanosegundo |
+| `cms_mutations.json` | Firmas y tokens editados nodo a nodo y bit a bit, cada edición como el nodo, la operación y el SHA-256 del resultado |
+| `cms_corpus.json` | Cada firma CMS y cada token de `security_cms.json` y de los fixtures `format3_signed_cms` y `format3_sealed` del borrador v0.12, leídos como los leen los veredictos de `capsule`, firmante a firmante |
+| `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 y `security_vectors.json` salen iguales en cada ejecución. 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` 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.
-- 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`, `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, BLS12-381 y el IBE.
+- 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.
+- 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.
 
 ## Licencia