Resumen

  • El texto base de SC-104 exige (MUST) la extensión no crítica Authority Information Access en los certificados de suscriptor TLS, aunque dentro de ella id-ad-caIssuers figura como SHOULD y id-ad-ocsp como MAY.
  • La propuesta sustituye ese MUST exterior por SHOULD y condiciona a la presencia de la extensión el mínimo de un AccessDescription. No modifica las dos reglas interiores.
  • caIssuers ayuda a localizar certificados del emisor para construir una ruta; OCSP identifica un servicio de estado. Tener uno no equivale a tener el otro, y compartir contenedor no los vuelve intercambiables.
  • El aviso público fijó el cierre de la votación para el 3 de septiembre de 2026 a las 00:00 UTC. Al corte de investigación del día 2, no corresponde afirmar resultado, revisión de propiedad intelectual terminada ni Guideline publicada.
  • La prueba completa necesita cinco estados: procedimiento, perfil normativo, método, certificado emitido y comportamiento de la parte usuaria. La huella del certificado y las versiones enlazan esos estados sin fusionarlos.

El resultado de una validación no revela su camino

Supongamos que un cliente acepta una conexión TLS. Ese resultado final no dice de dónde obtuvo el certificado intermedio. Pudo recibirlo del servidor, encontrarlo en un almacén local, recuperarlo de una caché, recibirlo de un sistema de precarga o descargarlo mediante una ubicación caIssuers. Tampoco dice qué mecanismo consultó para el estado del certificado.

Por eso, una discusión sobre AIA que empiece por “funcionó” o “falló” empieza demasiado tarde. Antes hay que identificar el texto aplicable, la extensión codificada, los métodos presentes, la cadena entregada por el servidor y la configuración del cliente.

SC-104 ofrece una ocasión concreta para ordenar esas pruebas. Su cambio es pequeño, pero atraviesa una frontera frecuente en la gobernanza técnica: una regla publicada no es una implementación, y una implementación no es el resultado de todos los usuarios.

Qué exigen hoy las tres capas

En el commit de base declarado por la papeleta, la tabla de extensiones de certificados de suscriptor marca authorityInformationAccess como MUST y no crítica. La sección siguiente exige que AuthorityInfoAccessSyntax contenga uno o más AccessDescription y limita los métodos admisibles.

La tabla interior asigna niveles distintos. id-ad-caIssuers es SHOULD; su ubicación es una URI HTTP del certificado de la CA emisora. id-ad-ocsp es MAY; su ubicación es una URI HTTP del respondedor OCSP. Cualquier otro accessMethod está prohibido.

Así, el contenedor es obligatorio y no puede estar vacío, pero ninguna de las dos rutas concretas es un MUST. caIssuers conserva una recomendación fuerte; OCSP es una facultad. Es incorrecto resumir ambos como métodos simplemente “opcionales” sin conservar esa diferencia.

El diff inmutable de SC-104 toca dos líneas. En la tabla exterior cambia MUST por SHOULD. En la regla de cardinalidad añade “If present”. No cambia OID, URI, multiplicidad, orden, función ni nivel de los métodos. Tampoco pretende reescribir todos los perfiles que usan AIA.

La pregunta formal es, por tanto, si la obligación del contenedor debe reflejar que ninguna ruta particular está garantizada. La pregunta operativa—qué se rompería, ahorraría o desplazaría—necesita otro conjunto de datos.

La diferencia entre una excepción y una ausencia sin explicación

RFC 2119 no usa SHOULD como sinónimo informal de “si apetece”. Permite apartarse cuando existen razones válidas, después de entender y ponderar cuidadosamente las consecuencias. RFC 8174 delimita el uso normativo de estos términos en mayúsculas.

Si SC-104 llega a ser texto vigente, omitir AIA dejaría de contradecir un MUST. Aun así, una CA tendría que poder mostrar por qué se apartó del SHOULD, qué perfil autorizó la decisión y qué certificados quedaron incluidos. La ausencia de esos datos no convierte automáticamente el certificado en inválido, pero sí hace imposible distinguir una excepción gobernada de un accidente.

El diseño de auditoría debe conservar al menos tres estados locales: inclusión conforme al comportamiento recomendado, omisión mediante excepción motivada y desviación no explicada. Añadir simplemente un campo Booleano “permitido” haría que el nuevo SHOULD perdiera su función.

El mismo cuidado evita otra simplificación. Un certificado con AIA puede contener sólo caIssuers, sólo OCSP o ambos, conforme a las reglas aplicables. La presencia del envoltorio no responde cuál de ellos existe. Cada método merece su propia fila.

Dos identificadores, dos superficies de dependencia

RFC 5280 ubica dentro de AIA información y servicios del emisor. caIssuers puede ayudar a seleccionar una ruta de certificación al ofrecer acceso a certificados emisores. OCSP localiza un servicio de protocolo de estado en línea.

La dependencia que crea cada uno es distinta. Para caIssuers importan la construcción de ruta, la disponibilidad del certificado intermedio, el formato del recurso y las políticas de descarga. Para OCSP importan la política de estado, el respondedor, la vigencia de la respuesta y otras reglas aplicables. Una medición de latencia OCSP no prueba disponibilidad de caIssuers; una descarga de emisor no prueba que se verificó la revocación.

Los propios Baseline Requirements hacen depender ciertas reglas de CRL de la existencia de un método OCSP dentro de AIA. Esa interacción refuerza la necesidad de guardar el método exacto. “AIA ausente” puede tener consecuencias diferentes de “AIA presente sin OCSP”.

También hay que registrar el papel del servidor. Un servicio TLS correctamente configurado entrega una cadena apropiada. Que un cliente pueda recuperar un intermedio que falta constituye una vía de resiliencia, no una licencia general para que el servidor omita su cadena. SC-104 no cambia ese reparto por sí solo.

Windows y Firefox muestran variables, no una ley universal

Microsoft documenta la recuperación AIA de certificados emisores en Windows y permite a los administradores desactivarla. El comportamiento no se describe correctamente con una etiqueta de marca. Hay que anotar versión, política, almacén, caché, conectividad, recurso remoto y cadena del servidor.

Mozilla explicó en 2020 que Firefox podía precargar certificados intermedios divulgados mediante Remote Settings. El objetivo incluía reducir errores de emisor desconocido cuando un sitio no enviaba correctamente el intermedio. Esa distribución puede evitar una descarga caIssuers en algunos casos, pero no demuestra cobertura total, igualdad entre versiones ni irrelevancia de la cadena del servidor.

Ambos documentos sirven como ejemplos limitados. No miden la población de clientes dependientes de AIA y no predicen el resultado de SC-104. Un equipo Windows administrado, un perfil Firefox con material precargado y un dispositivo integrado sin recuperación de red forman tres entornos distintos incluso frente al mismo certificado.

La observación responsable indica cuál fue la fuente real del intermedio. Sin ese dato, una validación exitosa puede ocultar que una caché o precarga compensó el cambio del emisor. El sistema parece robusto hasta que desaparece la compensación.

El reloj institucional también forma parte de la evidencia

El anuncio del voto identifica como proponente a Ethan Davis, de Google Trust Services, y como endorsers a Roman Fischer, de SwissSign, y Stephen Davidson, de DigiCert. Declara como base la versión 2.2.9 de los Baseline Requirements y enlaza una comparación entre los commits ad77bf… y a0f9a7….

El periodo de discusión se situó del 20 al 27 de agosto de 2026 UTC; el voto, del 27 de agosto al 3 de septiembre a las 00:00 UTC. Esta cronología impide tratar el diff como norma consumada el 2 de septiembre.

El procedimiento del CA/Browser Forum separa, además, el voto satisfactorio de la revisión IPR y de la publicación de una Final Maintenance Guideline. Una etiqueta “merged” o un correo de resultado no sustituye el número de versión final ni su fecha de efecto. Si el texto cambia, hay que conservar la relación entre el objeto votado y el publicado.

El recibo institucional debería guardar identificador, base, propuesta, ventanas, censo y denominadores por clase, votos, resultado, estado IPR, exclusiones, Guideline final y vigencia. El historial se acumula; no se reescribe con el estado más reciente.

La matriz de cinco estados

Procedimiento: SC-104, commits, discusión, voto, IPR y publicación. Responde quién autorizó qué y cuándo.

Perfil: tipo de certificado, versión del documento, nivel exterior de AIA, criticidad y vigencia. Responde qué regla era aplicable.

Método: OID, propósito, nivel, tipo de ubicación, cantidad y orden para caIssuers y OCSP por separado. Responde qué podía o debía alojar el contenedor.

Emisión: CA, producto, versión de plantilla, huella del certificado, bytes AIA y cada descripción observada. Responde qué fue emitido.

Uso: producto cliente, versión, plataforma, política, almacén, caché o precarga, cadena del servidor, red, descarga, fuente del intermedio, mecanismo de estado y resultado. Responde qué ocurrió en un contexto reproducible.

Las versiones y la huella permiten unir las filas. No autorizan atajos causales. Un certificado conforme puede fallar por otra causa; uno que se aparta de un SHOULD puede validarse; un cliente puede completar la ruta sin tocar AIA. La matriz permite describir cada caso sin hacer que el resultado reinterprete la regla.

La idea de Lu Heng de una especificación inicial mínima, decisiones futuras localmente verificables y adopción voluntaria ayuda a fijar esta disciplina. No implica que Lu Heng haya examinado SC-104. Sugiere una frontera: la norma común debe ser determinista en lo que regula; la realidad local necesita pruebas locales.

Lo que no sabemos todavía

Las fuentes revisadas no cuantifican cuántos certificados contienen AIA, caIssuers u OCSP. No muestran qué CA cambiaría su producción, ni el ahorro de tamaño, ni la exposición de privacidad, ni el tráfico, ni la tasa de fallos. Tampoco identifican a una parte usuaria que dependa de una combinación concreta.

Esto no invalida la razón formal de la propuesta. Si los métodos interiores no garantizan una ruta particular, rebajar el contenedor puede ser una armonización sensata. Pero una lógica normativa no equivale a un estudio de impacto.

Quien apoye el cambio no debe convertir la precarga de Firefox en prueba universal de independencia. Quien lo rechace no debe convertir la recuperación de Windows en prueba universal de dependencia. Ambos necesitan poblaciones definidas y pruebas reproducibles.

Un cambio pequeño con afirmaciones pequeñas

SC-104 puede terminar aprobado, modificado o rechazado. Las CA pueden mantener AIA aun si la regla pasa a SHOULD. Los clientes pueden conservar sus mecanismos, y los operadores seguirán decidiendo la cadena que entregan.

La gobernanza mejora cuando cada actor publica la porción que controla. El Forum publica el recibo normativo. La CA publica su perfil y excepción. El observador conserva los bytes. El fabricante o laboratorio documenta la ejecución. Ninguno habla por los demás.

Entonces ya no será necesario afirmar “AIA dejó de ser necesaria”. Bastará una descripción verificable: qué texto estaba vigente, qué método apareció en qué certificado y qué cliente hizo qué en unas condiciones declaradas.

Esa es la escala adecuada para juzgar dos líneas.

Fuentes

  1. Lu Heng, “Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption”
  2. CA/Browser Forum, pull request 665 de servercert — SC-104
  3. Comparación inmutable de SC-104
  4. CA/Browser Forum, issue 673 de servercert
  5. Archivo público del aviso de votación SC-104
  6. TLS Baseline Requirements en el commit base de la papeleta
  7. Bylaws del CA/Browser Forum
  8. RFC 5280, sección 4.2.2.1
  9. RFC 2119
  10. RFC 8174
  11. Microsoft, recuperación de Authority Information Access
  12. Mozilla Security Blog, precarga de certificados de CA intermedias en Firefox