Summary

  • La revisión 04 añade una única implementación: CygnetSSL, propietaria, operada en un entorno administrado por una sola entidad y sin pruebas independientes de interoperabilidad.
  • Los 22 certificados ECDSA, la CRL y el cambio de estado OCSP verifican un recorrido acotado de CA; no demuestran los cinco mecanismos de exportación y agregación que el borrador identifica como faltantes.
  • Daniel Kade propone una matriz de evidencia de cierre para que cada afirmación conserve requisito, artefacto, entorno, método, fecha y limitación. No es una norma de IETF.

El dato nuevo viene con un perímetro

La revisión 04, fechada el 13 de septiembre, incorpora una sección de estado de implementación. No estaba en la revisión 03, y el diff oficial permite aislar la adición.

No es todavía una decisión de estándares. El Datatracker lo presenta como Internet-Draft individual activo. Su API de metadatos muestra la versión 04, el estado I-D Exists y ningún stream de IETF. La cabecera propone carácter informativo; no acredita adopción de grupo, aprobación de IESG ni RFC.

La implementación citada es el controlador de autoridad certificadora CygnetSSL de Sanctum SecOps. Cubre emisión y revocación, validación de cadenas y perfiles, generación y publicación de CRL y respuestas OCSP sobre OpenSSL 3. El borrador no esconde sus límites: funciona en una sola propiedad administrada, es propietario, no ofrece el código fuente y no ha pasado una prueba de interoperabilidad contra una implementación independiente.

También registra observaciones del 12 de septiembre. Se emitieron y verificaron 22 certificados finales con dos perfiles; todos usaron ECDSA P-384 y ECDSA-SHA384. Se publicó una CRL DER y un certificado pasó de OCSP good a revoked después de revocarlo. Son resultados concretos de operación de CA.

No son despliegue poscuántico. Que el proveedor FIPS de OpenSSL estuviera activo no convierte por sí solo al conjunto en preparación PQC. FIPS 204 y FIPS 205 normalizan familias de firma poscuántica; la población observada en la entrada usa ECDSA clásica.

Cada brecha exige otro artefacto

REQ-RG-1 pide registros estructurados de los algoritmos negociados por sesión en TLS 1.3. REQ-RG-2 busca un inventario por zona de algoritmos DNSSEC exportado por resolutores. REQ-RG-3 quiere una distribución de familias criptográficas en el ámbito de X.509/CRL y OCSP. REQ-RG-4 extiende el problema de TLS a QUIC. REQ-RG-5 agrega el estado del entorno y exige compatibilidad con CBOM.

El controlador de CA se acerca al tercer ámbito, pero el texto de implementación no describe la exportación requerida. Veintidós emisiones no representan la distribución de certificados consultados en toda una infraestructura de estado. Faltan esquema, consumidor, ventana, denominador y reproducción. El borrador tampoco afirma que CygnetSSL haya cumplido REQ-RG-3.

Para TLS, QUIC, DNSSEC y CBOM no se registra ningún ejercicio equivalente. La conclusión correcta no es que el software sea defectuoso, sino que esos renglones permanecen sin evidencia de cierre en esta revisión.

La regla de running code ya contiene el freno

El marco citado, RFC 7942, busca que los debates técnicos conozcan el código existente. Recomienda declarar madurez, cobertura, versiones compatibles, licencia, experiencia, contacto, fecha y pruebas de interoperabilidad. A la vez separa una descripción aportada por un contribuyente de una verificación o un aval de IETF.

Por ser información temporal, la sección debe retirarse antes de publicar una RFC. La revisión 04 reproduce el límite de no aval y anuncia su eliminación. Informa bien de madurez y licencia. Lo que aún no ofrece es la tabla que conecte cobertura con REQ-RG-1 a REQ-RG-5.

La inspección pública también tiene fecha. La versión dice que el repositorio CygnetLib contiene pruebas JSON. En el corte de investigación, esa URL exacta respondió HTTP 404 desde el servidor de producción. Puede tratarse de una ruta corregible y no demuestra nada sobre intención o existencia pasada. Sí impide que un lector revise hoy el artefacto señalado.

Una matriz evita que el sustantivo cambie de significado

Daniel Kade propone una matriz de evidencia de cierre de brechas. Por fila: brecha y requisito; mecanismo; producto y versión del borrador; artefacto estable; operador y entorno; método; población y denominador; resultado; límites; fecha; responsable; próxima revisión; y reproductor independiente cuando exista.

Así, “una CA emitió 22 certificados ECDSA y comprobó una revocación” conserva todo su valor. “Existe el exportador de REQ-RG-3” necesita otra prueba. “El entorno está listo para PQC” necesita además TLS, QUIC, DNSSEC, agregación y unión con CBOM. Ninguna frase cancela a la anterior; simplemente ocupa otro nivel.

En The Policy Mirror, Heng Lu trata la frontera entre mecanismo y autoridad como parte del diseño. La Minimum Initial Specification favorece registros mínimos que no eliminan la decisión local. Why BTW Media Exists exige no convertir una señal comprobada en una realidad más amplia por conveniencia narrativa.

Sources

  1. Borrador PQC, revisión 04
  2. Revisión 03
  3. Diferencia oficial 03–04
  4. Registro Datatracker
  5. API de metadatos
  6. RFC 7942
  7. RFC 8446
  8. RFC 4034
  9. RFC 5280
  10. RFC 6960
  11. RFC 9000
  12. NIST FIPS 204
  13. NIST FIPS 205
  14. Enlace CygnetLib citado
  15. The Policy Mirror
  16. Minimum Initial Specification
  17. Why BTW Media Exists