@ -22,6 +22,7 @@ Estado al parar la sesión del 26 por el límite semanal de uso. Se actualizó e
- Dan una identidad X25519 que entra como un destinatario más, así que el formato no cambia.
- Está en la página (`b617007` y `67d626e`) y en la CLI de Go, con `-words` y `-words-file` en `encrypt` y `decrypt` (`5b3d2d4`, rama `v0.11`). Las dos comparten un vector, y la CLI abrió una cápsula hecha en la página. El detalle está en [spec_v0.11/llave_palabras.md](spec_v0.11/llave_palabras.md).
- **Firma de autor:** el [plan](PLAN_firma_go.md), con los cambios que pidió el autor: firma con certificado reconocido (`alg` 2, CAdES separada), hecha fuera de la web y nativa en escritorio, móvil y CLI; escritor en dos tiempos; sello RFC 3161 de una autoridad cualificada; OpenTimestamps en estudio.
- **Nota pública:** decidida para la v0.11, con una copia, junto con la fecha, en la `.dkk`. Los ficheros fuera de la cápsula quedan como propuesta. Las dos, en el [plan de la firma](PLAN_firma_go.md).
- **El área de firmas y sellos:** el autor no está convencido de fijar su tamaño. La consulta para Fable y Astra está en [spec_v0.11/area_firmas_para_revision.md](spec_v0.11/area_firmas_para_revision.md) y en un artefacto privado, https://claude.ai/artifact/8hVZGDWpv6ZqzzxcWVS7Rc.
| 0 | Borrador del spec v0.11: qué se firma (`AUTHOR_MESSAGE`), Ed25519 estricto, las claves `dkauthor1…`, los veredictos de la firma y la llave de palabras | Texto para que lo apruebe el autor |
| 0 | Borrador del spec v0.11: qué se firma (`AUTHOR_MESSAGE`), Ed25519 estricto, las claves `dkauthor1…`, los veredictos de la firma, la llave de palabras y la nota pública | Texto para que lo apruebe el autor |
| 1 | `ed25519strict`: la verificación estricta, con código propio para lo que `ed25519.Verify` de Go acepta de más | Los casos de «Taming the many EdDSAs» en `ed25519_strict.json` |
| 2 | `authorkey`: generar la clave, escribirla como `dkauthor1…` y `DKAUTHOR-SECRET-KEY-1…`, y guardarla en un fichero cifrado con contraseña (`age` scrypt, logN 16) | Pruebas de ida y vuelta y de errores |
| 3 | Firmar en el escritor: `payload_commit`, `control_commit`, `head_digest` y la firma en el área de seguridad, verificada antes de escribir | Una cápsula firmada que abre un lector de la v0.10, que muestra F1 |
@ -53,3 +53,14 @@ Por eso:
1. **Dónde se guarda la clave secreta de autor.** El diseño propone un fichero cifrado con contraseña. Como con la llave de palabras, podría poder guardarse también como palabras. Pero a diferencia de esa llave, la clave de autor es una sola para todas tus cápsulas, así que unas palabras flojas la exponen todas a la vez. Recomendación: fichero cifrado y, como alternativa, 12 palabras generadas al azar, nunca elegidas por la persona.
2. **Una sola firma por cápsula.** El diseño deja un único hueco de firma, ampliable más adelante sin cambiar el formato. Recomendación: así.
## Otras novedades de la v0.11 (01-10)
- **Nota pública.** Un texto corto que se ve antes de la fecha, para saber qué es cada cápsula: una extensión no crítica de `PUBLIC_HEADER`, registrada en §72, de hasta 1 KiB y con las reglas de texto de §29.6. Un lector de la v0.10 la ignora y abre la cápsula igual.
- Antes de la fecha no está comprobada: cualquiera puede fabricar una cápsula con la nota que quiera. La página y la CLI la muestran como nota de quien la creó, sin comprobar.
- Al abrir, `header_binding` la ata a la cápsula, y la firma la cubre a través de `control_commit`. Cambiarla después rompe la cápsula.
- **La nota y la fecha, también en la `.dkk`**, como pidió el autor, en una extensión no crítica (§44), para reconocer una llave suelta.
- Es informativa, porque nada la ata a la cápsula. La `.dkk` se empareja con su cápsula por `capsule_id` y `capsule_digest`, que ya escriben Go y TypeScript, nunca por la nota.
- Si la cápsula y la llave traen notas distintas, manda la de la cápsula y se avisa de la diferencia.
- **Código:** en Go, las dos extensiones y `-note` en la CLI, con el paso 5; en la página, con su propio plan.
- **Ficheros fuera de la cápsula**, propuesta pendiente de que el autor la confirme. Cada fichero iría dentro, como hoy, o fuera (IPFS, Drive, una URL), cifrado con la misma clave, con su hash, su tamaño y sus direcciones en una extensión crítica del head. Sus riesgos: que el fichero dure, que se pueda borrar antes de la fecha, que el cifrado quede público y que la web no pueda descargarlo de cualquier sitio.
