datekeys-doc/revision_externa/NOTA_PARA_EL_AUTOR.md

Nota para el autor: el paquete de la revisión externa

6 de octubre de 2026. En el repo docs, corregida el mismo día con una revisión del paquete y con tus decisiones.

Qué contiene

En inglés, porque el revisor puede no leer español:

Fichero	Para qué
README.md	La carta: qué es DateKeys, qué se pide, qué se entrega, qué queda congelado y que todas las revisiones hasta hoy son de IA
design_overview.md	El diseño criptográfico, autocontenido y con sus §, para leer en una hora
threat_model.md	Objetivos, no objetivos y modelo de amenazas (§4, §5, §7, §36.1, §55), con lo nuevo de la v0.14
scope_and_questions.md	Alcance, 12 preguntas ordenadas y 17 problemas ya conocidos (K1 a K17), para que no se redescubran
artifacts.md	Repos, commits, cómo pasar los gates, los vectores uno a uno, las dependencias con versión y la trazabilidad
precedence_and_language.md	Propuesta: español normativo, precedencia texto > CDDL > testdata > implementación, y los cambios de texto para la próxima versión

Tus decisiones (6-10)

1. Idioma y precedencia: aprobada la propuesta, con dos cambios: un párrafo al final de §1, no un §0, para no descolocar la numeración; y la regla 4 sin «vectores disputados». Una discrepancia es un defecto, decide el texto, se anota en el HANDOFF y se corrige en la versión siguiente con su caso en §76; hasta entonces los vectores no se tocan, porque los gates no lo permiten. Entre implementaciones, la de referencia primero, como dicen §16 y §67. Si el inglés pasa a normativo se decide en la v1.0.

2. Las etiquetas del §76: la v0.15 no se abre ahora. La carta ya declara que todas las revisiones anteriores son de IA. El texto corregido, con la precedencia y el registro de la revisión externa (§75, punto 10), va en la versión que se abra con los hallazgos del revisor. Así se evita un ciclo de tres repos antes de enviar.

3. TypeScript: la 0.3.0, cerrada el 6-10 en 3abd7bf, sobre 4e23f88, con el tag v0.3.0 y main avanzado; ese commit está en la tabla congelada de la carta y en artifacts.md. No es estética: v0.2.0 tiene el testdata en spec-v0.13 y no tiene la prueba de tlock_steps.json, así que el revisor no podría pasar el TypeScript contra los vectores congelados. Renombrar la carpeta App no hace falta: el revisor ve el nombre del bundle.

4. Traducción: primero, buscar un revisor que lea español. Elimina la decisión y el trabajo de contrastar cada hallazgo con el texto normativo. Si no lo hay, traducir solo el núcleo normativo, con un borrador de IA y tu revisión: §4 a §7, §10 a §13, §26 a §44.1, §51 a §57, §62.1, §63 y §69 a §72, unas 30 600 palabras de las 52 600 del texto. El resto lo cubre design_overview.md, y §76 se resume en una página. La carta dice que toda traducción es informativa y que tú contrastas cada hallazgo con el texto español: ese trabajo es tuyo.

5. Revisor y alcance: dos niveles, con presupuesto cerrado por nivel.

   • Nivel 1, obligatorio: el protocolo y el Go de referencia como evidencia, con Q1 a Q4, Q6 a Q8 y Q10 a Q12.
   • Nivel 2, aparte u opcional: Q5 y Q9, el lector CMS/X.509/RFC 3161 y las reglas del localizador, que son revisión de parsers y piden otro perfil.
   • TypeScript y Dart, fuera del alcance pagado, disponibles si el revisor quiere mirarlos.

   El paquete sirve tal cual como pliego para pedir precio. Una opción gratuita antes de pagar: enseñar Q1 y Q10 al equipo de drand, que son preguntas sobre su propio IBE. Es decisión tuya, porque supone enseñar el proyecto fuera.

6. Qué se comparte y cómo.

   • git bundle de los tres repos con todo el historial y los tags, porque §76 cita commits y el testdata de TypeScript apuntaba a spec-v0.13; y un .tar de cada árbol en el commit congelado, con su SHA-256, para quien no quiera bundles.
   • El código entero: sin él no puede decir dónde discrepa la implementación ni pasar los gates.
   • El repo docs, no. Si el revisor lee español, los cinco ficheros que cita artifacts.md §6, en una carpeta aparte; si no, se quitan esas referencias.
   • Un NDA mutuo simple hasta la publicación, y en el encargo, el consentimiento para nombrarle en §76.
   • La entrega, cifrada con age a la clave pública del revisor, con el SHA-256 del archivo por otro canal. El contacto de la revisión es tu dirección directa; info@ queda como contacto de seguridad del repo.

Documentación atrasada: arreglada

La sesión corrigió el 6-10 lo que el paquete encontró atrasado en datekeys-go, en 22f184c de la rama v0.14, sin tocar el texto normativo: el título y la fila §12.1 de docs/traceability.md, los tres schemes y los 18 errores de los README (son uno y 19), la cabecera de spec/datekeys.cddl y las releases firmadas de SECURITY.md, que aún no existen. Queda docs/README.md, que llama datekeys-ts/ a la carpeta que en esta máquina es App: se arregla al renombrarla.

Lo que no he podido comprobar

• Que el H3 del texto coincide con h3 de kyber: lo dice el spec y lo comprueban los vectores (tlock_steps.json, generado contra kyber), pero quien escribió el paquete no leyó kyber. Está como pregunta Q10.

Orden

1. Cerrar la 0.3.0 de TypeScript: hecho, 3abd7bf.
2. Pasar los tres gates en los commits congelados, con el fuzzing de Go en 39b2033, que el último fuzzing dejó cuatro commits atrás.
3. Corregir la nota y el paquete: hecho el 6-10 (la cabecera, el paso duplicado, artifacts.md §5, la propuesta, los dos hashes del CDDL), y la tabla congelada con la 0.3.0: hecho.
4. Elegir revisor y nivel de alcance, y pedir presupuesto.
5. Traducir el núcleo, solo si el revisor no lee español.
6. NDA, bundles y envío.
7. Tras el informe: la versión siguiente, con la precedencia, las etiquetas del §76 y el registro de la revisión (§75, punto 10).

La medida del área de 32 KiB con firmas reales (§74, §75, punto 13) sigue abierta. No bloquea la revisión, pero el revisor la verá como K2; si se hace antes, el perfil CMS que revisa sería el definitivo.