|
|
|
|
@ -0,0 +1,111 @@
|
|
|
|
|
# Revisión adversarial del borrador del spec v0.11 (1-10-2026)
|
|
|
|
|
|
|
|
|
|
*Tres revisores en paralelo (Opus 5.5) sobre el borrador `e224119` de `datekeys-go`: criptografía, interoperabilidad y privacidad. Sus informes van tal como los entregaron. Las decisiones del autor y cómo se resuelve cada punto están en el [plan de la firma](../PLAN_firma_go.md#revisión-del-borrador-01-10).*
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
## 1. Criptografía y vinculación
|
|
|
|
|
|
|
|
|
|
### Bloqueante
|
|
|
|
|
|
|
|
|
|
**B1. §29.11, §29.10 (CAdES-T), §29.12 y §29.7: la TSA no se autentica, así que cualquiera puede fabricar un sello válido.**
|
|
|
|
|
- **Problema:** el token se verifica con el certificado que trae él mismo, y su cadena no se ancla en nada («DateKeys no comprueba su cadena»). Es justo lo que §13 prohíbe con drand: aceptar como raíz una clave que llega con el dato. §7.9 solo contempla una TSA real deshonesta, pero aquí cualquiera puede hacer de TSA. Ninguna decisión del autor impide anclar la TSA: §5 solo deja fuera la cadena del firmante.
|
|
|
|
|
- **Escenario con `alg` 1:**
|
|
|
|
|
1. Ana firma con `alg` 1 y sella una cápsula `time_only`.
|
|
|
|
|
2. Tras la fecha, Mallory la abre, quita la firma y el sello y firma con su propia clave.
|
|
|
|
|
3. Añade un token firmado con un certificado fabricado a nombre de «FNMT-RCM TSA», con el EKU timeStamping y un genTime anterior a la ronda.
|
|
|
|
|
4. Los pasos 1 a 6 pasan, y el lector muestra F4 y S4: «Según FNMT-RCM TSA, existía el …, antes de que la cápsula pudiera abrirse».
|
|
|
|
|
5. Se cumple así la condición de §29.12 para ofrecer guardar la clave de Mallory, y la de §29.7 para decir que se firmó antes de la fecha.
|
|
|
|
|
- **Con `alg` 2:** quien tenga la clave de un certificado, o fabrique uno (M1), retrodata su CAdES-T. Comprobar la validez del certificado en genTime deja de servir.
|
|
|
|
|
- **Arreglo:** fijar en el lector unas anclas de TSA, como el perfil de §13 (las TSA cualificadas de la lista de confianza de la UE, o una lista publicada con el SDK); exigir la cadena hasta un ancla, válida en genTime, y tomar ‹TSA› del ancla, no del token. Un token que no encadena recibe un veredicto propio («autoridad no reconocida: no prueba nada»), que no cuenta para §29.12, §29.7 ni F6. Sin anclas, hay que retirar esas tres consecuencias.
|
|
|
|
|
|
|
|
|
|
### Mayores
|
|
|
|
|
|
|
|
|
|
**M1. §29.7 (F6 y S4): textos sin comprobar dentro de un veredicto.** ‹titulares›, el emisor y ‹TSA› los escribe quien hace el certificado, y la firma del certificado no se comprueba. Un certificado fabricado con «CN=JUAN ESPAÑOL» y emisor «AC FNMT Usuarios» da F6: «Firmado con certificado por JUAN ESPAÑOL». Además, esos textos no pasan por §29.6: un CN con LF, ESC o U+202E mete en la salida de la CLI una línea que imita un veredicto. Arreglo: un texto como «Firma válida de un certificado a nombre de ‹titular›; DateKeys no ha comprobado quién lo emitió»; fijar el atributo que se muestra (el CN) con las reglas del autor declarado de §29.6 y 256 bytes como máximo, o el SHA-256 del certificado si no las cumple; lo mismo para ‹TSA› y para los firmantes que se muestran aparte.
|
|
|
|
|
|
|
|
|
|
**M2. §29.11: `SIG_PART` no está definido cuando hay clave 2 y no es un `alg` 1 que cumple su perfil** (`alg` 2 con clave 3, un `alg` desconocido, un `alg` 1 con una clave de 33 bytes). Un lector usa 0x00 y da S4 o S3; otro da S2. Con un `alg` futuro, un lector v0.11 daría S3 a un sello válido, en contra de §70. Arreglo: la definición del diseño, válida para cualquier `alg`: `SIG_PART = 0x01 ‖ SHA-256(prefijo ‖ bytes exactos del contenido de la clave 2)`.
|
|
|
|
|
|
|
|
|
|
**M3. §29.10 contradice a §29.7 y §64 sobre F1, F5 y los firmantes que se muestran aparte.** Las reglas 3 y 4 piden exactamente un certificado por firmante, «y ninguno más», y un SignerInfo por hash; un fallo de 1 a 5 es F1, y F1 va antes que F5. Retirar un firmante exigido da F1, mientras que §64 espera F5; un SignerInfo ajeno rompe la regla 3 y da F1, así que «se muestra aparte» nunca se alcanza; falta el veredicto de un genTime fuera de la validez del certificado y el de un SignerInfo repetido. Arreglo: F1 solo para fallos estructurales de lo presente; F5 para un firmante ausente, sin sello, no verificable o con el certificado fuera de validez en t; decidir si se admiten firmantes ajenos.
|
|
|
|
|
|
|
|
|
|
**M4. §29.10 y §29.11: huecos del perfil CMS y del token.** No se exige que el content-type del token sea id-ct-TSTInfo ni que message-digest sea el hash del eContent: un verificador que solo valida la firma de signedAttrs aceptaría un token con genTime y messageImprint reescritos. Tampoco el ESSCertID o ESSCertIDv2 de la TSA (RFC 3161 §2.4.1, RFC 5816), ni si el SHA-1 del signing-certificate v1 de muchos tokens está en «la lista». Para messageImprint, §29.11 dice SHA-256 y el paso 5 acepta el que declare el token. No se fija el algoritmo de signing-certificate-v2 ni su relación con `SIGNERS`; debe haber exactamente un `signature-time-stamp` con un solo valor, y falta qué se hace con otros atributos no firmados. RSA sin máximo: Go 1.26 no limita el módulo y Web Crypto suele rechazar más de 16 384 bits. Fijar entre 2048 y 4096 bits, los OID admitidos y que el hash de la firma sea el de digestAlgorithm.
|
|
|
|
|
|
|
|
|
|
**M5. §44.1: direcciones sin restricciones y un aviso falso.** Cualquiera puede fabricar una `.dkk` con tlock para una ronda pasada, cuyo localizador se lee en el acto, y el lector abriría `file://…`, `\\host\share` (con el que Windows envía el hash NTLM), `http://192.168.1.1/…` o un fichero enorme. Arreglo: solo https (e ipfs a través de una pasarela https), sin userinfo, sin IP de loopback, privadas ni link-local, sin redirecciones a otro esquema, con un tamaño máximo y mostrando el host. «Nadie puede bajarla antes» no es cierto: la baja quien la aloja y, en IPFS, quien vea su CID en la DHT.
|
|
|
|
|
|
|
|
|
|
### Menores
|
|
|
|
|
|
|
|
|
|
- **m1. §29.9:** no dice si incumplir las reglas 1 a 3 es F1 o F2. Los fixtures `format3_signature_unsupported` y `format3_seal_unsupported` llevan `alg` 1 con una firma aleatoria (S ≥ ℓ): si es F2, contradice §76 y §64; conviene rehacerlos con un `alg` sin definir. noble 2.4 `verify` usa la ecuación con cofactor también con `zip215: false` (`edwards.js`), no solo con zip215. El perfil acepta una A de orden mixto con una R de orden pequeño, que libsodium rechaza: dar el resultado esperado de cada caso de «Taming the many EdDSAs».
|
|
|
|
|
- **m2. §55.1, §27, §63 (paso 15), §72 y §73** siguen diciendo «solo una extensión de firma» y que «`security` tampoco prueba nada»; como §55.1 es normativa, prohíbe mostrar F3, F6 y S4.
|
|
|
|
|
- **m3. §38.1:** el texto fija Unicode 18, pero TS usa `normalize('NFD')` y `toLowerCase()` de la plataforma, y Go `unicode.ToLower` (Unicode 15.0.0): U+A7CB pasa a U+0264 en Node 24 y no en Go, así que una llave con esa letra hecha en la página no abre en la CLI. Generar la tabla de minúsculas como la de NFD; rechazar controles, Default_Ignorable y Cn (un U+200B pegado deja la cápsula sin abrir). Sin `capsule_id` en la sal, la misma frase da la misma identidad en toda cápsula de esa ronda: un solo intento prueba a la vez todas las cápsulas de una ronda popular.
|
|
|
|
|
- **m4.** S4 debería exigir genTime + accuracy < round_time. §29.12 no dice si vale `DKAUTHOR1…` en mayúsculas ni exige los bits de relleno a cero. §24.1 no dice qué reglas de §29.6 se aplican. Conviene definir `CONTROL_SIG` como recodificación del mapa. Hay que fijar el mensaje de la firma de prueba. Para los cofirmantes, que firman un hash que no pueden recalcular, «lo que prueba» dice demasiado.
|
|
|
|
|
|
|
|
|
|
### Comprobado y correcto
|
|
|
|
|
|
|
|
|
|
`AUTHOR_MESSAGE` mide 66 bytes; las concatenaciones son inyectivas y cada valor tiene su prefijo; `u32(alg)` impide confundir `alg`; retirar o cambiar un firmante invalida todas las firmas. Poner L a cero no toca `SEALED_CONTROL_LEN` ni `header_binding`; `header_binding` ata PRELUDE y `PUBLIC_HEADER`, con la nota; `payload_commit` ata `I_PAYLOAD` sin revelarla; `head_digest`, con la sal, fija el contenido y lo oculta. Los trasplantes fallan; tras la fecha solo se rehacen el área y L. Con `alg` 1, `SIG_PART` ata el sello a la firma. Las reglas Ed25519 son exactas y suficientes, y lo que dice de Go 1.26 es correcto. Las longitudes bech32 y el vector de la llave de palabras se reproducen; el conjunto de espacios coincide en spec, Go y TS. Un lector v0.10 da F1 a `alg` 2 y acepta el área de 64 KiB.
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
## 2. Codificación, coherencia e interoperabilidad
|
|
|
|
|
|
|
|
|
|
### Bloqueantes
|
|
|
|
|
|
|
|
|
|
**B1. §29.10: los puntos 3 y 4 del perfil chocan con F5 y con «aparte».** Con SIGNERS = {hA, hB} y el SignerInfo de B retirado, §64 y «Verificación» dan F5, pero el punto 4 con la precedencia de §29.7 da F1. Un SignerInfo de fuera de SIGNERS, con su certificado, da F1 por el punto 3, no «aparte». Un CAdES-T en BER da F1 por el punto 1 y F5 por §29.11; un genTime fuera de la validez del certificado no está asignado. Arreglo: un procedimiento por firmante en un orden fijo; los puntos 3 y 4 solo fijan la forma (cada `sid` lleva a un único certificado, ningún certificado sin SignerInfo, como mucho un SignerInfo por certificado); la presencia de todos los de SIGNERS se comprueba solo en F5; un SignerInfo de fuera nunca cuenta; el token se juzga solo por §29.11.
|
|
|
|
|
|
|
|
|
|
**B2. Los vectores de la v0.10 cambian de veredicto, y §76 dice que no.** En `security.json`, «a signature of alg 1» (A = 11…11, firma = 22…22) pasa de F1 a F2; «a signature and a seal», de F1/S1 a F2/S1; «a seal of seal_type 2» (token 33…33, que no es DER), de S1 a S2. Los fixtures `format3_signature_unsupported` y `format3_seal_unsupported` pasan de F1 a F2. Choca con §76, §64, §67 y `testdata/README.md`. Arreglo: rehacer los casos «no soportado» con un `alg` y un `seal_type` sin definir, conservar los actuales como casos de F2 y S2, y corregir esos textos.
|
|
|
|
|
|
|
|
|
|
### Mayores
|
|
|
|
|
|
|
|
|
|
**M1. §29.9: ¿F1 o F2 cuando fallan las condiciones 1 a 3?** Escribir «otra longitud: F1; un fallo de 1 a 4: F2», y dar el veredicto de cada caso en §64.
|
|
|
|
|
|
|
|
|
|
**M2. §29.11: `SIG_PART` solo está definido sin clave 2 o con `alg` 1.** Con una cápsula de la v0.12 con `alg` 3 y su sello, un lector v0.11 puede dar S3, S1 o S2. Arreglo propuesto: con una clave 2 que no sea un `alg` 1 válido, S1 sin verificar.
|
|
|
|
|
|
|
|
|
|
**M3. El perfil CMS y el del token no fijan los bytes exactos.** No dice si exige el orden de los SET OF ni si alcanza a los certificados, respuestas OCSP y tokens de dentro (`encoding/asn1` y `cryptobyte` de Go aceptan un SET OF desordenado: una cofirma con los signerInfos en orden de inserción da F6 en un lector y F1 en otro). No hay tabla de OID: si vale `rsaEncryption`, si el hash de `signatureAlgorithm` debe coincidir con `digestAlgorithm`, qué parámetros lleva PSS, y si los de SHA-2 van ausentes o NULL. Con `seal_type` 2, un imprint SHA-512 correcto da S4 en un lector y S3 en otro. Arreglo: DER de X.690 con los SET OF ordenados, una tabla cerrada de OID, el hash de la firma igual a `digestAlgorithm`, el imprint dentro de la lista con SHA-256 fijo en `seal_type` 2, y vectores con firmas reales de la FNMT y del DNIe.
|
|
|
|
|
|
|
|
|
|
**M4. Las reglas CDDL de la `data` de extensiones contradicen §54.** `note-data`, `capsule-data` y `capsule-locator` son reglas normativas del CDDL, y §57 da `ERR_NON_CANONICAL_CBOR` a cualquier violación: una nota de 1 025 bytes haría que un lector rechace la cápsula en el paso 4 y otro la abra con la extensión inutilizable, como piden §54 y §69.1. Arreglo: exceptuar esas reglas en §57 y en el CDDL.
|
|
|
|
|
|
|
|
|
|
**M5. §24.1 y la regla 23 remiten a §29.6, que tiene dos reglas de texto:** la del comentario admite TAB y LF; la del autor declarado no. «Para Lucía␊en su cumpleaños» es válida para un lector e inutilizable para otro. Decir cuál se aplica.
|
|
|
|
|
|
|
|
|
|
### Menores
|
|
|
|
|
|
|
|
|
|
- **m1.** Restos de la v0.10 en §55.1 (normativa), §27, §63 paso 15, la nota de §72 y «trust model» de §73.
|
|
|
|
|
- **m2.** `datekeys.capsule`: la clave 1 es `tstr` en el CDDL, pero el texto pide un `dk1_` canónico; no se dice si el plaintext del localizador sigue §58, ni qué pasa si su ronda o su cadena no son las de la DateKey; «notas distintas» no dice si se comparan los bytes.
|
|
|
|
|
- **m3.** §76, cambio 1: con un head de 117 bytes y el área de 32 KiB, la carta de 2 000 bytes da L = 34 897 y P = 36 864, no 34 816. P = 8 704 con firma solo sale con un área ajustada de 6 144 bytes exactos; con 6 KiB de firma más su mapa, el área mide 6 656 y P = 9 216.
|
|
|
|
|
- **m4.** §38.1: Go usa `unicode.ToLower` (Unicode 15.0) y la página `toLowerCase` de Node 24 (Unicode 16.0); Node y Unicode 18 difieren en 48 puntos (U+A7DD → U+0277). La NFD de la plataforma coincide hoy con la de Unicode 18. Generar la tabla con `pathrule/gen`.
|
|
|
|
|
- **m5.** Flujos: §61 paso 12 decodifica `SECURITY_CBOR` y `CONTROL_CBOR` antes de las firmas y de la ampliación (la regla 17 debe aplicarse a los definitivos); §62 paso 18 escribe `capsule_digest` «si se incluye», contra el MUST de §43 y §44.1 con localizador; §29.2 deja ampliar cuando se pide, la regla 13 solo si las firmas no caben.
|
|
|
|
|
- **m6.** No hay vectores de `control_commit`, `signers_digest`, `AUTHOR_MESSAGE` ni `SEAL_SUBJECT`; «cada prefijo… seguida del byte 0x00» permite leer un 0x00 doble. Calcularlos sobre `format3_single`.
|
|
|
|
|
|
|
|
|
|
### Comprobado y correcto
|
|
|
|
|
|
|
|
|
|
Todas las referencias existen. Cuadran los ejemplos de §29.2, los 32 746 bytes a cero, la cota de 44 ficheros, los 66 bytes de `AUTHOR_MESSAGE`, los 40 bytes de `CONTROL_SIG` en posiciones fijas (los bytes 59 a 90 y los 8 anteriores a los 2 últimos) y las longitudes bech32. El vector de §38.1 sale con un PBKDF2 independiente. Lo que dice §70 de los lectores v0.10 es cierto en Go y TS; `security.json` da X a una clave desconocida del mapa exterior; Go 1.26.8 acepta el caso de §29.9. Texto y CDDL coinciden en tamaños. Ampliar el área no cambia `SEALED_CONTROL_LEN`, `header_binding` ni `AUTHOR_MESSAGE`. El orden S2, S1, S3 de §29.11 cuadra con §29.7 y §64.
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
## 3. Privacidad, amenazas y lo que se promete
|
|
|
|
|
|
|
|
|
|
### Bloqueante
|
|
|
|
|
|
|
|
|
|
**B1. §29.7 (F6, S4), §29.10 a §29.12, §4, §5 y §7.9: los veredictos con certificado dan por comprobados nombres y fechas que nadie ha comprobado.** ‹titulares›, el emisor y ‹TSA› son el texto de unos certificados que cualquiera puede fabricar, y `genTime` lo fija esa «TSA». Escenario: pasada la fecha, Mallory abre una cápsula `time_only`, le quita la firma y la firma de nuevo con un certificado hecho por él a nombre de «GARCÍA LÓPEZ MARÍA - 12345678Z», con emisor «AC FNMT Usuarios», y un CAdES-T de una «TSA FNMT» también suya, fechado un mes antes: el lector da F6, «antes de la fecha de apertura». Con `alg` 1, ese sello falso cumple la primera condición de §29.12. Arreglo: textos que no den el nombre por comprobado, que S4 deje de contar como garantía en §29.12, o una lista de TSA fijada en el SDK.
|
|
|
|
|
|
|
|
|
|
### Mayores
|
|
|
|
|
|
|
|
|
|
**M1. §44.1, §24.1, §55.2, §7.9, §29.11: en IPFS no se cumple que nadie conozca la dirección antes, y la nota y la fecha quedan públicas para siempre.** Los CID se anuncian en la DHT y en indexadores; un rastreador que busque ficheros `DKC1` puede indexar `capsule_id` → CID, con su nota y su fecha, y como la `.dkk` lleva `capsule_id` en claro, su poseedor encuentra la cápsula antes de la fecha sin el localizador. `capsule_digest` se oculta en la `.dkk`, pero §7.9 propone publicarlo y §29.11 sellarlo fuera, y la `.dkk` «de red de seguridad» del plan lo lleva en claro. El ejemplo «Para Lucía, en su 18 cumpleaños», con la DateKey, da la fecha de nacimiento de una menor, y en IPFS no se puede borrar. Una cápsula `time_only` en IPFS la abre cualquiera en su fecha. Arreglo: publicar un sobre opaco, el `.dkc` cifrado con `age` para una identidad aleatoria cuya clave va en el localizador junto con el SHA-256 del sobre; usar un hash con dominio propio para publicar o sellar fuera; reescribir el aviso; cambiar el ejemplo.
|
|
|
|
|
|
|
|
|
|
**M2. §38.1: la sal de la llave de palabras no incluye `capsule_id`.** Las mismas palabras con la misma ronda dan la misma identity. La página fija la hora al minuto, así que «1-1-2030 00:00, Madrid» será la ronda de muchas cápsulas: un diccionario las ataca todas a la vez, porque PBKDF2 se paga una vez por intento y cada cápsula de más solo cuesta 16 operaciones X25519. Faltan avisos: no reutilizar una contraseña; una «palabra» no tiene longitud mínima («a b c d e f» se acepta); la puntuación cuenta. Arreglo: añadir `hex(capsule_id)` a la sal (§62 ya genera `capsule_id` antes de derivar la llave); rechazar (SHOULD) palabras repetidas o de menos de 3 letras; mostrar las palabras normalizadas y pedir que se escriban de nuevo.
|
|
|
|
|
|
|
|
|
|
**M3. §44.1, §72: el localizador no limita qué se descarga ni de dónde.** Las direcciones y `capsule_digest` los pone quien crea o retoca la `.dkk`. Una `.dkk` de phishing con la fecha a un minuto puede llevar `javascript:…`, `file://atacante/x/c.dkc` (hash NTLM en Windows) o una IP interna. Arreglo: solo `https:` e `ipfs:` (CIDv1), URI ASCII según RFC 3986, sin redirecciones a otro esquema ni a direcciones privadas, mostrar el host; `capsule_size` en el localizador para cortar la descarga; decir que `capsule_digest` protege frente a quien aloja la cápsula, no frente a quien escribió la `.dkk`.
|
|
|
|
|
|
|
|
|
|
**M4. §55.2: no dice qué revela una firma con certificado.** El certificado lleva el nombre y el NIF, y la entidad si es de representante; tras la fecha lo ve quien pueda abrir la cápsula, y en `time_only`, cualquiera. La petición OCSP, normalmente por HTTP sin cifrar, revela el número de serie y el momento de la firma. Si la TSA no admite CORS, un intermediario de DateKeys vería la IP, el instante y el hash de cada cápsula firmada. Exportar la firma a VALIDe envía a un tercero el certificado de otra persona. Arreglo: declararlo, avisar antes de firmar, mostrar el nombre sin `serialNumber`, y pedir el OCSP y el sello desde el dispositivo o declarar el intermediario.
|
|
|
|
|
|
|
|
|
|
**M5. §7.9: faltan la firma a ciegas y la aplicación de firma.** Se firman 66 bytes binarios que nadie puede leer; un organismo que cofirma nunca ve el contenido, pero F6 dirá «Firmado por… y el organismo»; una web comprometida o una aplicación de firma falsa puede obtener firmas sobre cápsulas que la persona no ha visto. Faltan el firmante coaccionado y la revocación de claves `dkauthor`. Arreglo: declararlo; escribir `AUTHOR_MESSAGE` y el mensaje de prueba como texto legible, con un código corto que DateKeys muestre para compararlo; dar el head a los cofirmantes; permitir borrar una clave guardada.
|
|
|
|
|
|
|
|
|
|
### Menores
|
|
|
|
|
|
|
|
|
|
- **m1. §24.1:** con saltos de línea, una nota puede imitar «Firmado con certificado por…» antes de la fecha. Aplicar las reglas del autor declarado; mostrar antes de la fecha «Nadie puede comprobar antes de la fecha quién creó la cápsula ni si va firmada»; no convertir la nota en enlace ni ofrecer editarla; añadirla a §7.3.
|
|
|
|
|
- **m2. §44.1:** el localizador no lleva relleno, así que su longitud delata cuántas direcciones hay y de qué tipo. Darle un tamaño fijo.
|
|
|
|
|
- **m3.** §55.1, §27, §63 (paso 15) y §72 siguen diciendo que solo «una extensión de firma» prueba autoría.
|
|
|
|
|
- **m4. §61, §62, regla 12:** en el móvil, el navegador puede descartar la pestaña mientras la persona firma en otra aplicación; guardar un borrador deja `I_PAYLOAD` y el contenido en reposo. Prohibirlo o definir un borrador cifrado.
|
|
|
|
|
- **m5. §29.10:** AutoFirma firma por defecto en CAdES implícita y con la cadena completa; permitir que el escritor quite `eContent` y pode la cadena, lo que no invalida la firma.
|
|
|
|
|
- **m6. §76, cambio 1:** con el área de 32 KiB y un head de 100 bytes, la carta de 2 KB da P = 36 864, no 34 816.
|
|
|
|
|
|
|
|
|
|
### Comprobado y bien
|
|
|
|
|
|
|
|
|
|
Firmar o sellar no cambia `PUBLIC_HEADER_LEN`, `SEALED_CONTROL_LEN` ni P dentro de la reserva; cuadran los ejemplos de §29.2 y la cota de 44 ficheros. `AUTHOR_MESSAGE` y `SEAL_SUBJECT` no revelan el contenido. La firma y `header_binding` cubren la nota; el localizador no se lee antes de la fecha. La afirmación de §44.1 sobre IPFS es exacta para un `.dkc` de un solo bloque con CIDv1 raw, hasta 256 KiB con los valores por defecto de kubo (el CID se deriva del SHA-256, no «es» el SHA-256). Las dos defensas de §29.12 funcionan. Ya estaban declaradas la retirada de firmas tras la fecha, la equivocación y la fuga del área ampliada.
|
