Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Spec change proposal: resolve TRACE v0.2 verifier contradictions from #591

Abierto
  • ¿Algo no está bien?
#593 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Documentación
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
python
Área
documentation, security

Línea de trabajo

Read the v0.2 text in §§3.1, 3.1.5, 3.2.2, and 3.3, then review the per-input study and reproduction linked in #591. The proposed text, schema descriptions, and tests are expected in a linked draft PR; use them to check that each reported contradiction has a testable resolution. Done means the proposal has been discussed through the required 30-day comment period and has organizational sponsorship and Project Lead approval.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Spec sections affected
§3.1 (base-record fields and conformance levels), §3.1.5 (platform measurement appraisal), §3.2.2 (embedded signature), and §3.3 (verification sequence).

Problem
Issue #591 reports four reproducible disagreements between the v0.2 text, schema, and reference verifier: whether a base record requires tool_transcript and transparency; whether a signature checked only against the record's own cnf key authenticates origin; whether the verifier rejects a signed platform appraisal about another runtime measurement; and whether JWT-context ES256 support defines an ES256 top-level embedded signature. The report does not establish a deployed vulnerability.

Proposed change

  1. In §3.1, mark tool_transcript optional in the base record and required for Level 2 transcript checks. Mark transparency optional below Level 2 and required for Level 2 anchoring checks. Omission makes no transcript commitment or anchoring claim.
  2. In §3.3, require an issuer key trusted independently of the incoming record, or a signature chain validated to an accepted root, before reporting authenticated origin or a verification pass. Verify the signature against that trusted key and confirm that it matches cnf. A self-key-only check is diagnostic internal consistency.
  3. Retain the §3.1.5 rule that signed appraisal.platform_measurement.measurement equals this record's runtime.measurement, and enforce it in the reference verifier and conformance suite.
  4. In §3.2.2, specify Ed25519 with an OKP/Ed25519 cnf.jwk and a 64-byte signature for the v0.2 base embedded form. A different embedded algorithm needs a separately defined profile. JWT-context algorithms and separately defined enveloping profiles are unaffected.

The proposed text, schema descriptions, and tests will be in a linked draft PR. This issue starts discussion; it is not a request for immediate acceptance.

Backward compatibility

  • Non-breaking (new optional field, informative addition)
  • Breaking (changes algorithm set or accepted records)

Existing top-level embedded records using ES256 or another non-Ed25519 algorithm would need to use Ed25519 or a separately defined profile/enveloping form. Verifiers that accept only a self-supplied cnf key as authenticated origin must instead obtain an independent trust anchor. A signed appraisal about a different measurement must be rejected. Level 2 still requires transcript and anchoring evidence; base records without those fields remain valid at lower levels. Existing Ed25519 records with matching appraisals and separately defined enveloping signatures are unaffected.

Motivation
Give independent implementers and the reference library one testable interpretation of the same v0.2 record. See the per-input study and reproduction linked in #591. The required 30-day comment period, organizational sponsorship, and Project Lead approval remain open before any merge.

Related issues or PRs
#591

Lenguaje dominante
Python
Estrellas
37
Forks
33
Merge medio
1 d 4 h
PR fusionados (30 d)
122

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de agentrust-io/trace-spec

Todos los issues de agentrust-io/trace-spec

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.