Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>main
parent
76bf01d9f4
commit
e490b7bc95
@ -0,0 +1,61 @@
|
||||
# Borrador v0.14: decisiones para el autor
|
||||
|
||||
*6 de octubre de 2026. El borrador está en la rama `v0.14` de `datekeys-go` (`49b3764`), en `spec/DateKeys_Protocol_Specification_v0.14.md`. Sale del paso 2 de la [revisión de completitud contra la v0.13](../REVISION_completitud_v0.13.md): escribir lo que falta antes de la v1.0. No cambia ningún formato ni ningún veredicto, y su §76 recoge los siete cambios con su caso.*
|
||||
|
||||
Cada decisión trae la recomendación. Si las apruebas todas tal como están, basta con decir «apruebo el borrador», como con la v0.12 y la v0.13. La 8 es la única que cambia código.
|
||||
|
||||
## Lo que ya está escrito en el borrador
|
||||
|
||||
1. **Lo que no se garantiza (§5).** Añade que antes de la fecha nadie puede comprobar que una cápsula se abrirá, por lo que no sirve sola para demostrar una puja o una predicción; y tres no objetivos: caducidad, condiciones distintas de una ronda y cancelación.
|
||||
- Recomendación: aprobar.
|
||||
|
||||
2. **El proveedor (§7.6, §36.1).** §7.6 deja de ser una frase. Separa la confidencialidad hasta la fecha, que falla si el umbral de drand se pone de acuerdo, de la apertura después, que falla si drand deja de firmar o nadie guarda el release. Dice que no hay otra vía de apertura. Una cápsula `time_and_key` protege la primera y no la segunda, y el SDK oficial SHOULD recomendarla para horizontes largos o contenidos valiosos.
|
||||
- Recomendación: aprobar. Para la página `/create`, es un aviso más que habría que añadir cuando se apruebe.
|
||||
|
||||
3. **Los estados de un perfil (§71).** `activo`, `solo lectura` (no se escriben cápsulas nuevas, se siguen abriendo) y `comprometido` (se abren, con un aviso de que pudieron leerse antes). Una entrada publicada no se retira nunca del registro.
|
||||
- Recomendación: aprobar.
|
||||
|
||||
4. **Las firmas y los sellos frente a un adversario cuántico (§7.7, §53).** Dice que tampoco son post-cuánticos los recipients X25519, las firmas de autor ni las de las autoridades de sellado, y que un veredicto F3, F4, F6 o S4 leído décadas después prueba menos.
|
||||
- Recomendación: aprobar.
|
||||
|
||||
5. **El cliente web (§7.10, §59).** Un §7.10 nuevo cuenta con una página sustituida por quien controla el dominio o la construcción. §59 pide, como SHOULD, builds reproducibles con sus hashes publicados, Subresource Integrity en cada script, una política de contenido sin código de otro origen y un cliente que funcione sin conexión.
|
||||
- Recomendación: aprobar. La página ya tiene la política de contenido. Lo demás es trabajo para `datekeys-ts` cuando se publique la página.
|
||||
|
||||
6. **La entropía de la llave de palabras (§38.1).** El SDK oficial SHOULD ofrecer por defecto palabras al azar, al menos 6 de una lista pública de 2048 o más (unos 66 bits), y decir que unas palabras elegidas por una persona no son adecuadas para un contenido valioso. La derivación no cambia.
|
||||
- Alternativa: solo el aviso, sin generar palabras.
|
||||
- Recomendación: aprobar lo escrito. Generar palabras exige una lista, que sería un fichero de datos propio, no una dependencia: cuál, en qué idioma y de qué licencia lo decides tú cuando toque hacerlo.
|
||||
|
||||
7. **La raíz de confianza, byte a byte (§12, §35, §51, §63 pasos 10 y 11).** El spec ya no remite a «drand/kyber». Ahora escribe:
|
||||
- el mensaje que firma una ronda: SHA-256 de la ronda en 8 bytes;
|
||||
- su hash a G1, con la suite y el DST de RFC 9380;
|
||||
- la ecuación del paso 10;
|
||||
- H2, H3 y H4 del IBE de tlock, con sus etiquetas en bytes. H3 incluye el desplazamiento de un bit, que es fácil de implementar mal.
|
||||
|
||||
Lo ha sacado un agente del código de las tres implementaciones y de drand, kyber y tlock, y lo comprueba un vector nuevo, `tlock_steps.json`, con cuatro rondas publicadas y cinco stanzas.
|
||||
- Recomendación: aprobar.
|
||||
|
||||
## Lo que el borrador deja abierto
|
||||
|
||||
8. **Los tres schemes de §12.1.** §12.1 admite tres schemes de drand, pero el texto solo fija byte a byte el de Quicknet. Además, Go verifica los tres y TypeScript y Dart solo Quicknet, así que las implementaciones ya divergen.
|
||||
- A: dejarlo así.
|
||||
- B: admitir solo `bls-unchained-g1-rfc9380`, el de Quicknet. Cambia la validación de perfiles en Go, TypeScript y Dart, y ninguna cápsula válida.
|
||||
- C: admitir los tres al leer un perfil, y dejar que un lector rechace en el paso 10 los que el texto no fija.
|
||||
- Recomendación: **B**. Cierra la divergencia, y un proveedor nuevo sería un perfil nuevo (§10).
|
||||
|
||||
9. **«Una representación firmada equivalente» del perfil (§12).** El borrador la quita: ninguna implementación la tenía y nada la definía.
|
||||
- Alternativa: moverla a «Trabajo futuro» de §74.
|
||||
- Recomendación: dejarla quitada.
|
||||
|
||||
10. **Los valores intermedios del hash a G1 en los vectores.** `tlock_steps.json` da el mensaje y el punto, pero no los valores intermedios de RFC 9380. Darlos exigiría que Go importe directamente kilic/bls12-381, que ya va en el módulo como dependencia indirecta.
|
||||
- Recomendación: no darlos. Dart ya comprueba su hash a G1 con los vectores de RFC 9380.
|
||||
|
||||
## Al aprobar
|
||||
|
||||
Como con la v0.12 y la v0.13:
|
||||
- la fecha de la cabecera;
|
||||
- `SpecVersion` 0.14;
|
||||
- el SHA-256 en `spec/README.md`;
|
||||
- el tag `spec-v0.14` y `main`;
|
||||
- TypeScript y Dart, con `testdata` en el tag y una prueba que recorra `tlock_steps.json`. En TypeScript, la guarda falla si un fichero de `testdata` no lo corre ninguna prueba.
|
||||
|
||||
Si eliges B en la decisión 8, también el cambio de código en los tres repos. Además, `ibe.ts` e `ibe.dart` dicen en un comentario que H3 «pone a cero el bit más alto», cuando el código lo desplaza, que es lo correcto: se corrige el comentario.
|
||||
Loading…
Reference in new issue