Summary

  • Un Internet-Draft individual propone /.well-known/company-certs como punto HTTPS para descubrir anclas privadas de uso específico sin instalarlas en el almacén global del sistema operativo.
  • La autenticación del origen, la vigencia X.509 y la preferencia por la cadena con valid_from más reciente no demuestran que el órgano competente de la empresa aprobara la sustitución. En un solapamiento, la confianza efectiva puede cambiar sin que aparezca ese mandato.
  • Daniel Kade propone un recibo de cambio de ancla que una la época exacta del objeto, las huellas anterior y nueva, el ámbito, la ventana de solapamiento, la autoridad aprobadora, la política local, la corroboración y la reversión. Es una propuesta editorial, no una exigencia del IETF.

Una rotación normal basta para mostrar la grieta

No hace falta comenzar con un atacante. Pensemos en una migración prevista: la compañía publica durante una semana la cadena que quiere retirar y la que la sustituirá. Así evita que todos los clientes deban cambiar a la misma hora. Las fechas son coherentes, los dominios permitidos pertenecen al nombre autenticado del endpoint y las dos cadenas sirven para el mismo contexto de uso.

El cliente cumple su tarea. Obtiene el objeto de la procedencia esperada y aplica una regla determinista. Sin embargo, el resultado solo prueba qué publicó el origen y qué seleccionó el software. No identifica al responsable de PKI que aceptó el ancla, al dueño de la aplicación que aprobó el alcance ni al mecanismo de emergencia que pudo saltarse el proceso habitual.

Una ancla no es un dato decorativo. Es un punto de partida que el validador recibe localmente. Al añadirla, ciertos caminos de certificación pasan de no confiables a aceptables para la aplicación. Por eso, el permiso para publicar el objeto equivale a una capacidad técnica de modificar autoridad. La organización necesita saber si esa capacidad y el mandato de ejercerla coinciden.

Qué dice el borrador y qué no dice

draft-doehle-company-certs-discovery-00 es un Internet-Draft individual fechado el 22 de julio de 2026, destinado a la vía Standards Track. En la fecha de corte solo existe la revisión -00. No es un RFC, no representa por sí mismo consenso del IETF y no acredita un despliegue.

El diseño define un objeto JSON con versión, authority_information y trust_anchors en /.well-known/company-certs. Cada ancla se asocia a un usage_context y a una o varias cadenas. Una entrada puede indicar valid_from, valid_until, una URL HTTPS del mismo origen, la cadena X.509 en PEM, datos de CRL u OCSP y una huella SHA-256.

Hay dos acotaciones esenciales. permitted_domains tiene que coincidir con un identificador DNS del certificado TLS validado para el endpoint o estar por debajo de él. isolated_store_required expresa que la ancla debe permanecer en un almacén específico de la aplicación. Si el cliente no puede aplicar el aislamiento, debería rechazarla.

El mecanismo no instala la CA privada en el almacén global, no sustituye la Web PKI ni matricula certificados finales. Tampoco proclama que una CA publicada sea segura o fiable para cualquier propósito. Su valor está en distribuir confianza privada con un contexto y un alcance más estrechos.

HTTPS es obligatorio y la validación del certificado del servidor importa. Esa autenticación atribuye la publicación al origen. No revela cómo se reparten dentro de la empresa los permisos sobre DNS, alojamiento, distribución de contenido, claves TLS, automatización de despliegue, operación de la CA y aceptación de riesgos.

El dominio no es un organigrama

RFC 8615 ordena el espacio .well-known y advierte que poder escribir un recurso de este tipo puede equivaler a hablar por todo el origen. En plataformas compartidas, un permiso aparentemente pequeño puede tener consecuencias mayores de las previstas.

Eso no invalida el modelo de origen. Al contrario, obliga a describirlo con precisión. “Servido por el dominio correcto” es una afirmación verificable. “Aprobado por la autoridad interna correcta” es otra. El operador web puede ejecutar un despliegue sin ser quien decide la política de PKI; el equipo de PKI puede crear la cadena sin ser dueño del uso que una aplicación hará de ella.

RFC 9525 ayuda a comprobar que la identidad TLS presentada está autorizada para el nombre de referencia que el cliente quiso contactar. No convierte la sesión en un acta de aprobación. La conexión puede terminar en el servidor correcto y aun así faltar una prueba independiente de que la nueva ancla debía publicarse.

La automatización no elimina esta separación. Puede aprobar cambios si tiene una política y un mandato explícitos. Hay que acotar qué contextos puede alterar, qué comprobación externa necesita, cuánto puede durar el solapamiento y quién puede detener o deshacer la operación. Un pipeline succeeded describe ejecución; no se concede a sí mismo legitimidad.

La fecha más nueva no es una firma de autoridad

El borrador propone que, si varias cadenas siguen siendo aplicables al mismo uso, el cliente tome la que tenga el valid_from más reciente, salvo que la política local indique otra cosa. Es una regla útil para resolver una convivencia. No es un procedimiento de aprobación.

RFC 3339 normaliza la expresión de fechas y horas. El formato puede sostener el orden cronológico del documento, pero no explica por qué se eligió esa fecha, quién aceptó la ventana ni si dos equipos coordinaron el corte. Un valor posterior cabe por igual en una publicación correcta, equivocada o comprometida.

Tampoco lo decide RFC 5280. La validación de caminos trabaja con anclas y políticas que el cliente ya ha recibido como entradas. Puede demostrar que una cadena satisface esas entradas. No certifica el proceso por el que la ancla entró en el conjunto local.

Conviene conservar los verbos: el cliente “prefiere” una cadena; el órgano corporativo “autoriza” el cambio. Confundirlos hace que una regla de desempate acabe gobernando una transferencia de autoridad que nunca pretendió documentar.

El aislamiento debe verse en la práctica

isolated_store_required es una declaración del publicador, no un muro. El propio borrador explica que no impone técnicamente el aislamiento. La obligación pasa al cliente, que debe rechazar el material si su arquitectura no puede mantenerlo separado.

Una auditoría no debería limitarse a comprobar que el campo vale true. Tiene que saber dónde se cargó la ancla, qué bibliotecas y llamadas de validación pueden consultarla y si una caché compartida mezcla contextos. Una refactorización puede ampliar el alcance sin modificar el JSON.

Los dominios permitidos también requieren aplicación local. Un parser puede almacenar la restricción y el constructor de caminos ignorarla. Un componente puede reutilizar el mismo conjunto en otra aplicación. El registro debe unir la intención publicada con una observación de cumplimiento.

Si la ancla sale del almacén aislado y alcanza la confianza general, el cambio deja de ser un detalle. Se ha ampliado el radio de una autoridad privada. Esa ampliación merece una alarma y una decisión nuevas.

Frescura de transporte y vigencia del mandato

RFC 9110 y RFC 9111 explican la semántica de HTTP, la caché y la revalidación. El borrador pide cautela con datos antiguos y repeticiones, propone revalidar periódicamente y permite que el cliente imponga una frescura máxima.

Estas medidas responden si la representación del origen es suficientemente reciente. No confirman que la aprobación organizativa siga vigente. Una excepción de dos horas puede caducar mientras el objeto aún es fresco. Una revocación interna puede no haber llegado a todos los puntos de distribución. Un JSON recién servido puede contener una ancla que el dueño de la aplicación nunca aceptó.

La primera descarga es especialmente sensible. Antes de ella, el canal no aporta ninguna ancla; después, la aplicación puede validar caminos nuevos. Operativamente no debería parecerse a un refresco rutinario. Conviene distinguir alta inicial, actualización, solapamiento, corte, retirada y reversión.

Consultar con demasiada frecuencia también revela interés por una organización o un contexto. La caché protege disponibilidad y privacidad, pero su horizonte pasa a formar parte de la decisión de riesgo. No puede fijarse solo para ahorrar tráfico.

Revocar un certificado no explica una rotación

La metainformación admite ubicaciones CRL y OCSP. RFC 6960 ofrece un modo de consultar el estado de certificados. Es un control del ciclo de vida, pero no una biografía de la ancla.

Una CA nueva puede emitir certificados sin revocar aunque su incorporación no estuviera autorizada. La antigua puede seguir produciendo caminos válidos después de una retirada prevista. El estado de los certificados subordinados no dice por qué cambió el conjunto de confianza ni quién aprobó la convivencia.

La corrección tampoco acaba borrando una entrada del endpoint. Quedan cachés, clientes sin conexión, sesiones activas y posibles copias fuera del almacén aislado. La retirada tiene que identificar las poblaciones afectadas, la latencia máxima y la prueba de cierre.

Un recibo de cambio de ancla

La propuesta de Daniel Kade es un recibo de cambio de ancla de confianza. No añade por decreto campos al recurso público ni atribuye esta idea al IETF. Crea una pieza operativa que vincula publicación, autoridad y decisión local.

Primero fija el objeto: digest exacto del JSON, origen, identidad de referencia validada, hora de recuperación y estado de caché. Después fija el alcance: contexto de uso, dominios permitidos y obligación de aislamiento. La aprobación queda así atada a una época concreta, no a todo lo que la URL publique en el futuro.

El recibo describe la transición mediante huellas de las anclas vieja y nueva, identificadores de cadena, intervalos, ventana de solapamiento y estado pretendido. Añadir, preferir, retirar y revertir son operaciones distintas. Todas deben quedar nombradas.

La sección de autoridad señala el rol, la política o la automatización acotada que dio permiso, junto con una referencia protegida al expediente. No hace falta revelar datos internos en Internet. Sí hace falta que la prueba pueda verificarse sin depender exclusivamente del mismo canal de publicación.

La sección del cliente conserva qué regla aplicó, qué corroboración exigió, si logró aislar el material, cuándo revalidará y cómo actuará si el endpoint falla. El cierre enlaza CRL, OCSP, retirada urgente, reversión, clases de clientes y tiempo máximo de propagación. El propio recibo expira para impedir que una autorización antigua cubra un objeto nuevo.

Corroborar según el daño posible

Una herramienta interna de bajo impacto quizá necesite la autenticación del origen y una revisión firmada del repositorio. Una plataforma de pagos, firma o control de infraestructura puede exigir doble autorización o una clave bajo otro dominio administrativo. La política debe ser proporcional, no uniforme.

Dos señales no siempre son dos controles. Otra URL servida por la misma infraestructura o un correo emitido por la misma cuenta pueden compartir el mismo fallo. Son mejores candidatos un manifiesto firmado, un sistema PKI separado, un registro protegido o una clave de aprobación en hardware.

RFC 5011 solo ofrece una comparación limitada. En la actualización automática de anclas DNSSEC utiliza estados de incorporación, espera y retirada. No se aplica a Company-Certs. Su enseñanza útil es que cambiar automáticamente la base de confianza necesita memoria de transición, no solo un valor marcado como actual.

El protocolo puede seguir siendo sencillo

El Internet-Draft no tiene que codificar el gobierno completo de cada empresa. Ya aporta una frontera valiosa: origen autenticado, alcance de dominio, contexto de uso, periodos y señal de aislamiento. Es una mejora frente a distribuir un archivo de CA sin contexto o instalarlo globalmente.

La capa de gobierno comienza donde termina esa evidencia. Las fuentes no prueban despliegues, incidentes ni abusos reales. El caso inicial es una prueba de diseño basada en la propia regla de selección durante solapamientos.

El objetivo no es añadir ceremonias al GET, sino conservar significado. HTTPS autentica la recuperación. JSON representa metadatos. X.509 valida un camino con entradas locales. La política del cliente selecciona una cadena. La organización autoriza la modificación. El recibo relaciona los cinco hechos sin permitir que el primero se disfrace de los demás.

Fuentes

  1. https://heng.lu/the-policy-mirror/
  2. https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
  3. https://heng.lu/on-why-btw-media-exists-and-why-reality-not-advocacy-is-the-product/
  4. https://datatracker.ietf.org/doc/html/draft-doehle-company-certs-discovery-00
  5. https://datatracker.ietf.org/doc/draft-doehle-company-certs-discovery/
  6. https://datatracker.ietf.org/doc/draft-doehle-company-certs-discovery/history/
  7. https://www.rfc-editor.org/rfc/rfc8615.html
  8. https://www.rfc-editor.org/rfc/rfc9525.html
  9. https://www.rfc-editor.org/rfc/rfc5280.html
  10. https://www.rfc-editor.org/rfc/rfc6960.html
  11. https://www.rfc-editor.org/rfc/rfc9110.html
  12. https://www.rfc-editor.org/rfc/rfc9111.html
  13. https://www.rfc-editor.org/rfc/rfc8259.html
  14. https://www.rfc-editor.org/rfc/rfc3339.html
  15. https://www.rfc-editor.org/rfc/rfc5011.html