Esquema de firmaSignature scheme

Nota del traductor: este documento es informativo. Es una traducción al español del documento normativo en inglés "The DS1 token scheme". Ante cualquier discrepancia, el texto en inglés gobierna.

El esquema de token DS1

1. Alcance

Esta página especifica el formato a nivel de bytes de un token DS1:, de modo que una implementación independiente pueda decodificarlo, interpretarlo y verificarlo criptográficamente sin acceso al código fuente de este sistema. El §6 establece con precisión qué demuestra una verificación offline exitosa y qué no.

2. Gramática del token

token       = "DS1:" base45-payload
base45-payload = <codificación Base45 (RFC 9285) de deflated-cose>
deflated-cose  = <compresión DEFLATE en bruto (RFC 1951) de cose-bytes>
cose-bytes     = <codificación CBOR (RFC 8949) de una estructura COSE_Sign, etiqueta CBOR 98, según RFC 9052>

• DS1: es un prefijo de esquema ASCII literal, fuera de la carga útil Base45 y fuera de cualquier cosa que se hashee o firme. DS identifica el esquema ("DicomServer"); 1 es la versión del esquema.
• Un decodificador DEBE rechazar cualquier token que no comience exactamente con este prefijo, antes de intentar cualquier decodificación Base45 o inflado — fallar de forma cerrada ante una versión de esquema desconocida o futura, en lugar de intentar un análisis best-effort.
• Después del prefijo, los caracteres restantes se decodifican como Base45 (RFC 9285) y luego se descomprimen como un flujo DEFLATE en bruto (RFC 1951 — sin encabezado ni remolque zlib o gzip).
• Acotar el inflado. Un decodificador DEBE limitar el tamaño máximo inflado y rechazar el token si la descompresión lo superaría, en lugar de asignar un búfer sin límite. El límite de la implementación de referencia es de 8192 bytes; las cargas útiles de código de barras reales están, en la práctica, muy por debajo de 2 KiB. Un decodificador también DEBE tratar un resultado inflado que alcanza exactamente el límite como ambiguo con una carga útil truncada/bomba y rechazarlo, en lugar de aceptar un objeto posiblemente truncado.

3. Estructura del COSE_Sign

Los bytes descomprimidos son una estructura COSE_Sign codificada en CBOR (RFC 9052 §2, mensaje de "múltiples firmantes", etiqueta CBOR 98):

COSE_Sign = [
    body_protected : bstr,       ; encabezado protegido codificado en CBOR para el cuerpo
    body_unprotected : {},       ; siempre el mapa vacío
    payload : bstr,              ; cadena de bytes CBOR que contiene el documento JSON firmado
    signatures : [+ COSE_Signature]
]

COSE_Signature = [
    sign_protected : bstr,       ; encabezado protegido codificado en CBOR para esta firma
    sign_unprotected : {},       ; siempre el mapa vacío
    signature : bstr             ; ECDSA r||s en bruto de 64 bytes
]

• body_protected decodifica al mapa CBOR { 4: kid }, donde 4 es la etiqueta de encabezado 4 de RFC 9052 §3.1 para el identificador de clave y kid es una cadena de bytes CBOR: la huella SHA-256 en bruto (32 bytes) del certificado hoja del firmante, calculada sobre la codificación DER del certificado. Ver §4 sobre cómo un verificador resuelve esta huella de vuelta a un certificado.

• Los mapas de encabezado no protegido — tanto a nivel del cuerpo como de cada firma — son siempre el mapa CBOR vacío {} en este esquema. Ningún claim se transporta jamás sin proteger.

• payload es una cadena de bytes CBOR cuyo contenido es un documento JSON en UTF-8, canonicalizado según JCS (RFC 8785, JSON Canonicalization Scheme) antes de envolverse en la cadena de bytes. La forma campo por campo de este payload se documenta por separado (ver la página de referencia de claims COSE publicada junto a esta).

• signatures es un arreglo no vacío: un elemento por cada cofirmante del mismo payload, todos producidos con la misma clave de firma ES256 del hospital. El sign_protected de cada elemento decodifica a un mapa CBOR cuyo primer claim es { 1: -7 } (etiqueta de encabezado 1 de RFC 9052 §3.1 = algoritmo; -7 es ES256 según RFC 9053 §2.1), seguido de los claims de atestación de ese firmante (nombre, código de propósito de firma, correo electrónico, marca de tiempo, año, secuencia, id de registro, y los claims opcionales de cédula/designación — tabla completa en la página de referencia de claims COSE).

• signature es la firma ECDSA en bruto de 64 bytes (r de 32 bytes concatenado con s de 32 bytes), no ASN.1 DER. Se calcula sobre la Sig_structure de RFC 9052 §4.4 para ese elemento de firma:

  Sig_structure = [
      "Signature",              ; cadena de contexto, fija
      body_protected,           ; bstr, los mismos bytes de arriba
      sign_protected,           ; bstr, el encabezado protegido de este elemento de firma
      external_aad,             ; bstr, siempre vacío (longitud cero) en este esquema
      payload                   ; bstr, los mismos bytes de arriba
  ]
  

  la codificación CBOR de ese arreglo de 5 elementos es lo que se firma con ECDSA (resumen SHA-256, curva P-256, es decir, ES256).

4. Resolución de KID a certificado

Un verificador resuelve el kid en body_protected a un certificado real de la siguiente manera:

1. Para cada elemento de firma, lee el claim y de ese firmante (el año UTC de la firma, un entero) de su encabezado sign_protected.
2. Descarga https://pki.dicomserver.com/leaf-bundle-<y>.pem — un paquete PEM con todos los certificados hoja que estuvieron vigentes para firmar durante ese año calendario.
3. Calcula la huella SHA-256 de la codificación DER de cada certificado del paquete y selecciona el que coincide con kid byte a byte.
4. Encadena ese certificado hoja a https://pki.dicomserver.com/ca-bundle.pem — el paquete de confianza acumulativo de cada Autoridad Certificadora de la que este sistema haya emitido certificados hoja alguna vez. Los certificados CA de este paquete usan ECDSA P-384/SHA-384; los certificados hoja firman con ES256 (ECDSA P-256/SHA-256).

Un verificador que no pueda alcanzar ninguno de los dos paquetes (sin red) todavía puede validar la firma aritméticamente contra un certificado hoja obtenido por otros medios (por ejemplo, suministrado directamente), pero no puede establecer confianza en ese certificado sin la cadena — ver §6.

5. El claim de propósito de firma (r)

El claim r en el encabezado protegido de cada firmante transporta un código de propósito de firma ASTM E1762-95(2013) ("Standard Guide for Electronic Authentication of Health Care Information") — el mismo vocabulario que subyace al CID 7007 de DICOM y al conjunto de valores signature-type de FHIR (urn:iso-astm:E1762-95:2013).

Por compacidad del código de barras, el claim transporta solo el segmento hoja del OID — por ejemplo, "1" para Firma de autor, "13" para Firma de revisión — bajo la raíz fija y universalmente conocida 1.2.840.10065.1.12.1. Un verificador reconstruye el OID completo anexando la hoja a la raíz; la raíz misma nunca se transmite.

El vocabulario completo de 18 códigos, y el subconjunto que la interfaz de firma de este sistema realmente ofrece a un firmante humano, se publica como datos estructurados (astm-e1762-codes.json) y se renderiza como tabla en este sitio. Un valor del claim r que no aparece en esa tabla es un rol heredado en texto libre, anterior a la adopción del vocabulario ASTM por parte de este sistema; dichos valores se muestran al lector literalmente, sin resolverse a una etiqueta.

6. Declaración de alcance — qué demuestra la verificación offline y qué no

Una verificación offline exitosa de un token DS1: — decodificación Base45, inflado, análisis del COSE_Sign, resolución de KID, verificación ECDSA por firmante y (si hay red) validación de la cadena contra un paquete CA de confianza — establece:

• Quién atestiguó los bytes exactos del payload transportado en este token (el nombre, código de propósito de firma, correo electrónico y marca de tiempo de cada firmante), vinculado criptográficamente a esos bytes.
• Que esos bytes exactos del payload — los identificadores de hallazgo, los hashes de contenido, las referencias de estudio/paciente y el nombre del hospital incrustados en el payload — fueron firmados, sin modificaciones desde la firma.
• En qué carácter actuó cada firmante, mediante el claim r (§5).

No establece:

• Que el contenido firmado sea la versión vigente/más reciente del informe. El finding.version y el finding.sha256 del payload son una instantánea al momento de la firma; si el documento vigente ha sido editado, corregido o reemplazado desde entonces solo se puede saber consultando la página de validación en línea de ese registro, que vuelve a leer la base de datos vigente y recalcula un hash fresco para comparar. Un verificador offline no tiene ningún canal hacia esa información.
• El estado de revocación del certificado firmante. Este esquema no define ni consulta una CRL ni un respondedor OCSP; que una cadena valide estructuralmente contra el paquete CA no garantiza por ello que el certificado involucrado no haya sido revocado desde entonces.

Para certeza sobre vigencia o revocación, usar la página de validación en línea: el token offline es una prueba de atestación e integridad para los bytes que transporta, no un oráculo del documento en vivo.

Encabezados COSE

Claims por firmante

Campos del payload

Nota del traductor: este documento es informativo. Es una traducción al español del documento normativo en inglés "DS Text Profile v1 — canonical text algorithm". Ante cualquier discrepancia, el texto en inglés gobierna.

Regla de verdad de referencia: una implementación que falle cualquier vector publicado (§3) es no conforme. Una discrepancia significa que la implementación está mal — nunca significa que el vector está mal.

DS Text Profile v1 — algoritmo de texto canónico

1. Propósito

finding.text_sha256 es un resumen (digest) complementario al hash de bytes en bruto del payload, finding.sha256, calculado a partir de una extracción de texto canónico del mismo contenido — reproducible por un lector que transcribe la página impresa (a mano o vía OCR) y hashea el resultado para compararlo contra el valor transportado en el token.

Versionado por diseño: cualquier cambio futuro a este algoritmo se publica como un nuevo nombre de campo (text_sha256_v2, …), nunca como una redefinición silenciosa de text_sha256.

2. Algoritmo de texto canónico

El perfil compone estándares NOMBRADOS, cada uno citado para que una reimplementación independiente pueda converger en los mismos bytes sin leer el código fuente de ninguna implementación de referencia en particular. Los pasos se ejecutan en este orden exacto:

1. Analizar (parse) — un análisis HTML5 permisivo del contenido almacenado del hallazgo. Permisivo: el marcado malformado nunca lanza una excepción, se analiza de la mejor manera posible como HTML5, tal como lo haría un navegador. Una reimplementación DEBE usar un analizador HTML5 igualmente permisivo y conforme a la especificación (por ejemplo, el propio DOMParser de un navegador, o una biblioteca que implemente el algoritmo de construcción de árbol HTML5 de WHATWG) — un analizador estricto/XML que rechace HTML malformado del mundo real es no conforme.

2. Extraer — una extracción INSPIRADA en innerText, definida normativamente por ESTE perfil y sus vectores de prueba trabajados (§3) — NO por la implementación de innerText de ningún navegador. NO reutilizar el getter innerText de un navegador, ni una API DOM equivalente a un navegador, para reimplementar este paso; seguir las reglas de abajo exactamente, ya que los vectores publicados son la verdad de referencia para la conformidad, no el comportamiento real (dependiente del layout) de innerText.

   Recorrer el árbol analizado en orden de documento, emitiendo el contenido de los nodos de texto. Cada límite de nivel de bloque emite exactamente un separador de espacio ASCII (no un salto de línea — la salida del perfil es una única línea unida por espacios, colapsada aún más en el paso 6). La lista de elementos de bloque implementada es:

   p, li, td, th, tr, br, h1–h6, más div, ul, ol, table (defensivo — estos rara vez llevan texto directo, pero son límites si lo hacen).

   Todos los demás elementos (span, strong, em, a en línea, etc.) son en línea: no se emite ningún separador en su límite, de modo que fragmentos en línea adyacentes se unen sin espacio forzado. Los subárboles script y style se excluyen por completo — su contenido de texto nunca llega al paso de extracción. Los elementos img no contribuyen nada — tampoco el texto alt — según la regla de derivabilidad desde impresión: solo lo que un lector puede transcribir del papel participa en el resumen.

   Divergencias respecto al innerText del navegador (normativas — no es un comportamiento equivalente a innerText):

   • El separador de bloque se emite solo DESPUÉS del contenido de nivel de bloque, nunca según la posición de renderizado — este perfil no consulta el layout.
   • El CSS/estilo se ignora por completo: el texto con display:none / visibility:hidden sigue participando en el resumen, a diferencia del innerText real de un navegador, consciente del layout, que lo excluye.
   • Las imágenes y su texto alt se excluyen por completo.

3. Depurar UTF-8 inválido — aplicar una conversión UTF-8-a-UTF-8 que "ignora bytes inválidos" (implementación de referencia: iconv('UTF-8', 'UTF-8//IGNORE', $text) de PHP). Una reimplementación DEBE descartar por completo las secuencias de bytes inválidas, nunca sustituirlas por un carácter de reemplazo — independientemente de cualquier configuración de carácter sustituto por servidor, de modo que la misma entrada inválida canonicaliza de forma idéntica en cualquier servidor. Un fallo total de esta conversión se trata como cadena vacía. Si la normalización NFKC (paso 4) todavía devuelve un fallo después de esto, el resumen es null.

4. Normalización Unicode: NFKC (Unicode Standard Annex #15) — implementación de referencia: Normalizer::normalize($text, Normalizer::FORM_KC) (ext-intl de PHP). El plegado de compatibilidad maximiza la robustez de ida-y-vuelta impresión/OCR (²→2, ligaduras, formas de ancho completo).

5. Plegado de mayúsculas/minúsculas: Unicode Default Case Folding (completo), independiente de locale — implementación de referencia: mb_convert_case($text, MB_CASE_FOLD, 'UTF-8') (ext-mbstring de PHP). Es necesario porque el estilo text-transform de CSS puede hacer que las mayúsculas/minúsculas impresas difieran de los bytes almacenados. La independencia de locale es deliberada: la İ mayúscula con punto turca se pliega a "i" + punto combinante superior (U+0307) según el plegado de mayúsculas/minúsculas por defecto de Unicode, no según la regla turca de i sin punto. Una reimplementación DEBE usar un plegado de mayúsculas/minúsculas Unicode independiente de locale/por defecto, no una función de mayúsculas/minúsculas consciente de locale, o divergirá en entradas en turco/alemán/etc. El orden plegado-después-de-NFKC es cerrado/idempotente según "Character Model for the World Wide Web: String Matching" (charmod-norm) del W3C.

6. Colapso de espacios en blanco — colapsar cada racha que coincida con la propiedad Unicode White_Space (PCRE /[\p{White_Space}]+/u, incluye  /U+00A0, tabulaciones, saltos de línea) a un único espacio ASCII; recortar el espacio inicial/final. Una reimplementación DEBE usar la propiedad White_Space completa, no una clase de espacio en blanco solo-ASCII o la que trae por defecto un lenguaje de programación (ver la nota de portabilidad de clase de espacio en blanco en §4).

7. Resumen (digest) — hash('sha256', $canonicalText) (PHP) sobre los bytes UTF-8 del resultado del paso 6, en hexadecimal en minúsculas — el mismo primitivo usado para el hash de contenido en bruto finding.sha256.

Manejo de null/vacío (exacto a la implementación, no solo una convención)

• digest(null) → null (no hay contenido de hallazgo alguno que resumir).
• Una entrada vacía o solo-espacios-en-blanco (no nula) → el hash SHA-256 de la cadena vacía: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855. Esto es deliberadamente distinto del caso null: significa "el hallazgo existe y su contenido de texto está vacío", un hecho diferente de "no hay hallazgo".

Orden de linealización de tablas

El orden de linealización de tablas (el orden en que las celdas/filas se serializan en el flujo de texto) DEBE coincidir con el orden de lectura renderizado (por filas) — una tabla linealizada por columnas, o en cualquier orden específico del analizador, haría que text_sha256 divergiera entre dos analizadores HTML5 conformes aunque un lector humano vea el mismo texto. Cualquier implementación DEBE incluir fixtures explícitos de tablas en su suite de pruebas (ver el vector #2 y el vector #11 en §3).

3. Corpus de vectores — la verdad de referencia para la conformidad

La única fuente de verdad para la conformidad es un archivo legible por máquina, vectors.json, publicado junto a esta página: 14 vectores, cada uno { label, input_b64, canonical_text, sha256 }, donde input_b64 es la codificación en base64 de los bytes de entrada en bruto (de modo que el vector de UTF-8 inválido sobreviva el transporte como JSON). Cualquier implementación independiente de DS Text Profile v1 — incluido el propio validador offline de este sitio — DEBE reproducir el canonical_text y el sha256 de cada vector byte a byte dado el mismo input_b64.

El corpus se divide en 5 vectores mínimos por característica (una regla aislada por vector: separadores de bloque, linealización de tabla por filas, exclusión de script/style, normalización NFKC, manejo de UTF-8 inválido) y 9 vectores con la forma de la salida real del editor de texto enriquecido de este producto (marcas en línea anidadas, tablas, una imagen con data: URI, estilos, espaciadores).

La depuración de UTF-8 inválido (paso 3) es un no-op para los catorce vectores: todos los input_b64 ya son UTF-8 válido, o — para el vector dedicado de UTF-8 inválido — ya reducido a U+FFFD por el análisis del paso 1.

4. Requisito del modelo de analizador

Los vectores del corpus son todos marcado bien formado. La entrada malformada (<p>/<li>/<td> sin cerrar, </br> suelto, texto reubicado ("foster-parented") fuera de una <table>) es donde divergen las implementaciones: un analizador HTML5 de construcción de árbol WHATWG completo resuelve <p>Foo<p>Bar</p> a foo bar, coincidiendo con el orden de lectura humano; un analizador de solo tokenizador (basado en eventos, sin construcción de árbol) lo resuelve a foobar — un separador faltante, no solo una diferencia de espacio en blanco: el resumen mismo cambia.

Consecuencia: cualquier implementación de este perfil, incluido un verificador offline que consuma esta página, DEBE reimplementar §2 sobre un analizador HTML5 de construcción de árbol real — uno que ejecute el algoritmo de construcción de árbol de WHATWG, no un mero tokenizador/analizador basado en eventos — o divergirá silenciosamente en marcado malformado (pero común, del mundo real). Una implementación de solo tokenizador es útil solo como verificación cruzada portable contra los vectores bien formados, nunca como oráculo de conformidad para HTML almacenado arbitrario.

Dos matices de portabilidad:

• Clase de espacio en blanco. La comprobación integrada de "esto es espacio en blanco" de la mayoría de los lenguajes de programación no equivale exactamente a la propiedad Unicode White_Space (las diferencias incluyen caracteres de control, NEL U+0085 y U+FEFF según el entorno de ejecución). Una implementación debería codificar explícitamente los 25 puntos de código White_Space (U+0009–000D, 0020, 0085, 00A0, 1680, 2000–200A, 2028, 2029, 202F, 205F,
  3000. en lugar de depender del atajo nativo de un lenguaje.
• Plegado de mayúsculas/minúsculas completo. La función de conversión de mayúsculas/minúsculas por defecto de algunos entornos de ejecución es solo plegado simple de mayúsculas/minúsculas (por ejemplo, la ß alemana permanece como ß en lugar de plegarse hacia ss), no el plegado completo por defecto de Unicode que este perfil requiere (paso 5). Una implementación cuya función nativa de mayúsculas/minúsculas sea solo simple necesita una tabla o biblioteca explícita de plegado completo de mayúsculas/minúsculas.

Nota del traductor: este documento es informativo. Es una traducción al español del documento normativo en inglés "Examiner transcription rules". Ante cualquier discrepancia, el texto en inglés gobierna.

Reglas de transcripción para el examinador

1. Flujo forense offline

Verificar el contenido de texto de un informe impreso contra su text_sha256 firmado sigue cinco pasos:

1. Escanear el código QR COSE offline del informe y ejecutar la verificación estructural/criptográfica del esquema DS1 (decodificar → inflar → analizar COSE → resolver KID → verificar la firma, y encadenar a un paquete CA de confianza cuando hay conexión).
2. Leer el valor de finding.text_sha256 transportado en el payload COSE verificado, junto al veredicto automático.
3. Transcribir o aplicar OCR al texto del hallazgo impreso.
4. Aplicar los pasos de canonicalización publicados de DS Text Profile v1 (ver la página complementaria) al texto transcrito.
5. Hashear el resultado y compararlo contra el text_sha256 mostrado. Una coincidencia significa que las palabras de la página son, salvo la normalización declarada del perfil, el texto exacto que fue firmado. Una discrepancia significa "verificar en línea o volver a transcribir" — nunca un veredicto automático de falsificación por sí solo (ver la regla 5 más abajo).

2. Reglas de transcripción del examinador

Estas cinco reglas rigen cómo un examinador humano (o una herramienta de OCR complementaria) debe transcribir el texto de un hallazgo impreso antes de aplicar DS Text Profile v1 y hashearlo.

1. Transcribir solo el texto propio del informe — párrafos, encabezados, listas y tablas — en orden de lectura (izquierda a derecha, arriba hacia abajo). Ejemplo: una tabla se renderiza como filas y columnas en la página impresa; transcribirla fila por fila, de izquierda a derecha, de arriba hacia abajo (Region | Estado / Silueta cardiaca | Normal → "Region Estado Silueta cardiaca Normal"), nunca por columnas.

2. Omitir viñetas y marcadores de numeración de listas — copiar solo el texto del elemento. Ejemplo: un elemento de lista impreso con viñeta "• Una lista" se transcribe como "una lista", no como "e una lista" — un glifo de viñeta mal leído que filtra un carácter inicial espurio no debe sobrevivir a la entrada del hash.

3. Nunca transcribir texto que aparezca dentro de una imagen o figura — las imágenes se excluyen del resumen de texto por diseño. Ejemplo: el texto de un pie de figura o icono no forma parte de la prosa propia del hallazgo; el equivalente en el mundo real son las anotaciones DICOM grabadas ("burned-in") — superposiciones de paciente/lateralidad, pies de página incrustados — horneadas en una imagen diagnóstica — nada de eso participa en text_sha256 y nada de eso debería tipearse.

4. Copiar letra por letra exactamente lo que está impreso: conservar los acentos exactamente como se muestran (presentes o ausentes), no corregir la ortografía, y escribir superíndices/subíndices como caracteres ordinarios en el orden de lectura. Ejemplos: "x²" impreso se tipea como "x2" (la normalización NFKC del perfil pliega el punto de código de superíndice almacenado al mismo dígito plano en el lado firmado, de modo que firmante y examinador convergen); una "radiografia" impresa, deliberadamente sin acento, se transcribe como "radiografia", sin autocorregirla a "radiografía" — el examinador debe copiar exactamente lo que está impreso, con o sin acento, no la ortografía de diccionario.

5. Si se usa OCR automático, revisar su salida carácter por carácter contra la página impresa antes de hashear — un solo carácter mal leído cambia el hash. Una discrepancia significa "verificar en línea o volver a transcribir", nunca un veredicto automático de falsificación por sí solo.

Qué demuestra una coincidencia: las palabras de la página impresa son, salvo la normalización declarada del perfil (NFKC + plegado de mayúsculas/minúsculas + colapso de espacios en blanco), el texto exacto que fue firmado.

Qué permanece atestación-solamente offline, incluso con una coincidencia del resumen de texto: las imágenes (excluidas del resumen por diseño) y el formato/diseño (negrita, color, estilo de tabla, fuente) — una coincidencia del resumen de texto demuestra quién atestiguó el hallazgo y que esas palabras fueron firmadas, nunca que esta representación visual exacta fue firmada. El recálculo exacto byte a byte, imágenes incluidas, todavía requiere la página de validación en línea.

Nota operativa: las plantillas de impresión desactivan la separación silábica (hyphenation) en CSS — no aparece ninguna regla CSS hyphens en ninguna hoja de estilo de informe — así que la división de palabras a mitad de línea no es una preocupación al transcribir una página impresa.

Nota del traductor: este documento es informativo. Es una traducción al español del documento normativo en inglés "Manual validation walkthrough". Ante cualquier discrepancia, el texto en inglés gobierna. Los bloques de código (Python/bash) se mantienen idénticos al original en inglés para que puedan copiarse y ejecutarse literalmente.

Recorrido de validación manual

Este recorrido verifica un token DS1: a mano, usando solo python3 (biblioteca estándar más los paquetes base45 y cbor2) y el CLI de openssl. Cada comando de abajo es literal y está pensado para ejecutarse tal cual contra un token real; ajustar solo las rutas de marcador de posición (token.txt, el año del leaf-bundle, los nombres de host).

Los bloques de Python de abajo también se publican como un solo archivo: manual-validation.py.

Prerrequisitos:

python3 -m pip install base45 cbor2
openssl version   # cualquier OpenSSL reciente 1.1.1+/3.x funciona

Poner el texto del token escaneado/impreso en un archivo, por ejemplo:

printf '%s' 'DS1:6BF...' > token.txt

Paso 1 — Quitar el prefijo DS1:

token = open('token.txt').read().strip()

PREFIX = 'DS1:'
if not token.startswith(PREFIX):
    raise SystemExit(f'reject: missing/unknown scheme prefix (expected {PREFIX!r})')

b45_payload = token[len(PREFIX):]

Paso 2 — Decodificar Base45 (RFC 9285)

Usando el paquete base45:

import base45

deflated = base45.b45decode(b45_payload)

Alternativa sin dependencias (por si el paquete no está disponible — mismo alfabeto y misma regla de agrupamiento que RFC 9285: grupos de 3 caracteres decodifican a 2 bytes, un grupo final de 2 caracteres decodifica a 1 byte; un resto final de 1 carácter siempre es inválido):

_ALPHABET = '0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ $%*+-./:'
_REVERSE = {c: i for i, c in enumerate(_ALPHABET)}


def base45_decode(s: str) -> bytes:
    if len(s) % 3 == 1:
        raise ValueError('invalid base45 length (remainder of 1 is never valid)')

    out = bytearray()
    for i in range(0, len(s), 3):
        group = s[i:i + 3]
        try:
            values = [_REVERSE[c] for c in group]
        except KeyError as exc:
            raise ValueError(f'character not in base45 alphabet: {exc}') from None

        if len(group) == 3:
            value = values[0] + values[1] * 45 + values[2] * 2025
            if value > 0xFFFF:
                raise ValueError('base45 value out of range for a 2-byte group')
            out += value.to_bytes(2, 'big')
        else:
            value = values[0] + values[1] * 45
            if value > 0xFF:
                raise ValueError('base45 value out of range for a 1-byte group')
            out.append(value)

    return bytes(out)


# deflated = base45_decode(b45_payload)

Paso 3 — Inflar DEFLATE en bruto, con límite de tamaño (RFC 1951)

El flujo es DEFLATE en bruto — sin encabezado ni remolque zlib (RFC 1950) o gzip — de ahí wbits=-15. Acotar la salida para que un token manipulado no pueda actuar como bomba de descompresión; el límite de referencia es de 8192 bytes, y un resultado que alcanza el límite exactamente se trata como indistinguible de una carga útil truncada/bomba y se rechaza, no se acepta.

import zlib

MAX_INFLATED_BYTES = 8192


def bounded_raw_inflate(data: bytes, cap: int = MAX_INFLATED_BYTES) -> bytes:
    decompressor = zlib.decompressobj(wbits=-15)
    out = decompressor.decompress(data, cap)

    if len(out) >= cap:
        raise ValueError('reject: inflated payload reached the cap (bomb/truncation-ambiguous)')
    if decompressor.unconsumed_tail:
        raise ValueError('reject: inflated payload exceeds the size cap')
    if not decompressor.eof:
        raise ValueError('reject: truncated or corrupt DEFLATE stream')

    return out


cose_bytes = bounded_raw_inflate(deflated)

Paso 4 — Decodificar la estructura COSE_Sign (etiqueta CBOR 98, RFC 9052)

import json
import cbor2
from cbor2 import CBORTag

decoded = cbor2.loads(cose_bytes)
if not (isinstance(decoded, CBORTag) and decoded.tag == 98):
    raise SystemExit('reject: not a COSE_Sign (CBOR tag 98) object')

body_protected_bytes, body_unprotected, payload_bytes, signatures = decoded.value
if body_unprotected != {}:
    raise SystemExit('reject: unexpected non-empty unprotected body header')

body_protected = cbor2.loads(body_protected_bytes)
kid = body_protected[4]  # RFC 9052 §3.1 header label 4 = key identifier
print('kid (hex):', kid.hex())

payload = json.loads(payload_bytes.decode('utf-8'))
print(json.dumps(payload, indent=2, ensure_ascii=False))

parsed_signatures = []
for sign_protected_bytes, sign_unprotected, signature in signatures:
    if sign_unprotected != {}:
        raise SystemExit('reject: unexpected non-empty unprotected signature header')

    claims = cbor2.loads(sign_protected_bytes)
    if claims.get(1) != -7:
        raise SystemExit('reject: unexpected signature algorithm, expected ES256 (-7)')

    print('signer claims:', claims)
    parsed_signatures.append(
        {
            'sign_protected_bytes': sign_protected_bytes,
            'claims': claims,
            'signature': signature,
        }
    )

claims para cada firmante incluye n (nombre), r (código hoja de propósito de firma ASTM E1762 — ver la página del esquema DS1 §5 y la tabla de 18 códigos), e (correo electrónico), t (marca de tiempo de la firma), y (año UTC de la firma), s (secuencia), rec (id de registro), y opcionalmente c (cédula/licencia) y d (designación).

Paso 5 — Ubicar el certificado hoja por el KID

Descargar el paquete hoja anual para el año en el claim y del firmante, por ejemplo:

curl -sSfLo leaf-bundle-2026.pem https://pki.dicomserver.com/leaf-bundle-2026.pem

Verificación manual de un solo certificado con el CLI (huella de un certificado candidato):

openssl x509 -in candidate.pem -outform DER | sha256sum

Comparar ese resumen hexadecimal contra kid.hex() impreso en el paso 4. Para automatizar el escaneo de cada certificado del paquete:

import re
import subprocess

year = parsed_signatures[0]['claims']['y']
bundle_path = f'leaf-bundle-{year}.pem'

bundle_text = open(bundle_path).read()
cert_blocks = re.findall(
    r'-----BEGIN CERTIFICATE-----.*?-----END CERTIFICATE-----',
    bundle_text,
    re.S,
)

leaf_pem = None
for i, cert_pem in enumerate(cert_blocks):
    der = subprocess.run(
        ['openssl', 'x509', '-outform', 'DER'],
        input=cert_pem.encode('ascii'),
        capture_output=True,
        check=True,
    ).stdout
    fingerprint = subprocess.run(
        ['openssl', 'dgst', '-sha256', '-binary'],
        input=der,
        capture_output=True,
        check=True,
    ).stdout

    if fingerprint == kid:
        leaf_pem = cert_pem
        print(f'matched leaf certificate #{i} in {bundle_path}')
        break

if leaf_pem is None:
    raise SystemExit(f'reject: no certificate in {bundle_path} matches kid {kid.hex()}')

with open('leaf.pem', 'w') as f:
    f.write(leaf_pem)

Paso 6 — Encadenar la hoja al paquete de confianza

curl -sSfLo ca-bundle.pem https://pki.dicomserver.com/ca-bundle.pem
openssl verify -CAfile ca-bundle.pem leaf.pem

Se espera leaf.pem: OK. Los certificados CA de este paquete son ECDSA P-384/SHA-384; la hoja firma con ES256 (ECDSA P-256/SHA-256).

Paso 7 — Reconstruir la Sig_structure y verificar la firma

Reconstruir los bytes exactos que fueron firmados con ECDSA (Sig_structure de RFC 9052 §4.4) para el primer firmante, y luego verificar con openssl:

signer = parsed_signatures[0]

sig_structure_bytes = cbor2.dumps(
    [
        'Signature',
        body_protected_bytes,
        signer['sign_protected_bytes'],
        b'',  # external_aad — always empty in this scheme
        payload_bytes,
    ]
)

with open('sigstructure.bin', 'wb') as f:
    f.write(sig_structure_bytes)

Convertir la firma en bruto de 64 bytes r||s a ASN.1 DER, ya que openssl dgst -verify espera DER:

def _encode_der_length(length: int) -> bytes:
    if length < 0x80:
        return bytes([length])
    encoded = b''
    while length > 0:
        encoded = bytes([length & 0xFF]) + encoded
        length >>= 8
    return bytes([0x80 | len(encoded)]) + encoded


def _encode_der_integer(magnitude: bytes) -> bytes:
    magnitude = magnitude.lstrip(b'\x00') or b'\x00'
    if magnitude[0] & 0x80:
        magnitude = b'\x00' + magnitude  # keep it a positive INTEGER in DER
    return b'\x02' + _encode_der_length(len(magnitude)) + magnitude


def raw_to_der(raw: bytes) -> bytes:
    if len(raw) != 64:
        raise ValueError('expected a 64-byte raw r||s ECDSA P-256 signature')
    r, s = raw[:32], raw[32:]
    body = _encode_der_integer(r) + _encode_der_integer(s)
    return b'\x30' + _encode_der_length(len(body)) + body


sig_der = raw_to_der(signer['signature'])
with open('sig.der', 'wb') as f:
    f.write(sig_der)

Extraer la clave pública de la hoja y verificar:

openssl x509 -pubkey -noout -in leaf.pem > pub.pem
openssl dgst -sha256 -verify pub.pem -signature sig.der sigstructure.bin

Se espera Verified OK. Repetir el paso 7 para cada elemento de parsed_signatures cuando hay más de un cofirmante.

Paso 8 (opcional) — Recalcular text_sha256 a partir de una transcripción

Si el payload transporta un finding.text_sha256 (DS Text Profile v1, ver la página complementaria), compararlo contra un hash del texto impreso transcrito. Una transcripción — tecleada a mano o corregida de OCR según las reglas de transcripción del examinador — es texto plano, así que solo aplican los pasos de normalización de texto del perfil: NFKC, case folding completo, colapso de White_Space, SHA-256. No hay HTML que analizar. (Reproducir los vectores publicados, cuyas entradas son HTML en bruto, requiere además el paso de extracción del perfil sobre un analizador de construcción de árbol WHATWG — eso es prueba de conformidad, fuera del alcance de este recorrido.)

Coloca la transcripción en transcription.txt (UTF-8) y, solo con la biblioteca estándar:

import hashlib
import re
import unicodedata

# The 25 Unicode White_Space code points - do not substitute a runtime's
# native whitespace class (see the DS Text Profile v1 page's portability note).
_WHITE_SPACE_RE = re.compile(
    '[\t\n\x0b\x0c\r\x20\x85\xa0\u1680\u2000-\u200a\u2028\u2029\u202f\u205f\u3000]+'
)

transcribed = open('transcription.txt', encoding='utf-8').read()

normalized = unicodedata.normalize('NFKC', transcribed)
folded = normalized.casefold()  # Python's casefold() is full, locale-independent
collapsed = _WHITE_SPACE_RE.sub(' ', folded).strip()
computed = hashlib.sha256(collapsed.encode('utf-8')).hexdigest()
expected = payload['finding'].get('text_sha256')

print('computed:', computed)
print('expected:', expected)
print('MATCH' if computed == expected else 'MISMATCH — verify online or re-transcribe')

Los pasos 1 a 7 son la verificación criptográfica obligatoria; el paso 8 es opcional y solo aplica cuando hay un text_sha256 presente.