Resumen

  • Los 22 emisores y los tres consumidores de certificados que participaron votaron a favor de SC100, sin votos en contra ni abstenciones. Sin embargo, el 31 de agosto de 2026 la revisión de propiedad intelectual seguía abierta hasta el 5 de septiembre.
  • SC100 no declara una nueva obligación. Reordena y aclara reglas existentes: DNSSEC debe validarse en la perspectiva primaria para las consultas de control de dominio y CAA aplicables, con una excepción parcial para ciertos métodos por correo; en las perspectivas remotas puede validarse.
  • MPIC y DNSSEC no son intercambiables. MPIC exige corroboración desde puntos remotos; DNSSEC clasifica criptográficamente la respuesta observada por un resolutor.
  • El borrador excluye el conjunto completo de datos de consulta DNS de dos ámbitos de auditoría y registro, pero exige conservar información suficiente. La solución práctica es unir un recibo temporal del control del resolutor con un recibo de emisión que identifique papeles, consultas, estados y decisión.

La fecha del documento no cierra la revisión

La ficha oficial de SC100 permite reconstruir el estado sin interpretar silencios. Veintidós emisores votaron sí. Apple, Cisco Systems y Mozilla votaron sí como consumidores. El cuórum de 15 se cumplió y no hubo oposición ni abstenciones.

El voto terminó el 6 de agosto a las 17:00 UTC. Dos horas después comenzó una revisión IPR de treinta días, con cierre anunciado para el 5 de septiembre a las 19:00 UTC. Durante esa ventana todavía pueden presentarse avisos de exclusión de reivindicaciones esenciales. Las actas del 13 de agosto registran precisamente que la propuesta había entrado en revisión.

Hay dos documentos con la etiqueta 2.2.9. El anexo aceptado de SC100 se genera con esa versión y fecha del 6 de agosto, pero lleva la marca DRAFT. Las Baseline Requirements vigentes también son 2.2.9 y tienen la misma fecha; su historial termina en SC101. La página de documentos conserva el índice de publicaciones finales. SC100 aún no aparece como revisión incorporada.

Por eso una afirmación como “cumplimos 2.2.9” no identifica por sí sola el texto. Hace falta la condición documental: publicación vigente, borrador de mantenimiento en IPR o versión final posterior. El número es un dato; el estado es la autoridad normativa.

La propia moción exige otra precisión. SC100 no fija fecha de entrada en vigor porque pretende aclarar y consolidar sin modificar los requisitos. Este análisis no atribuye al borrador un endurecimiento ni una relajación. Estudia qué recibo haría comprobable la división que el texto expone.

La obligación existente tiene sujeto

SC085v2 hizo aplicable desde el 15 de marzo de 2026 la validación DNSSEC, cuando existe una cadena firmada, para las consultas relevantes de validación de control de dominio y CAA desde la perspectiva primaria. La versión actual mantiene las reglas dispersas.

El texto limpio de SC100 las agrupa en el §4.2.2.2. Primero define la capacidad del resolutor de la perspectiva primaria: algoritmo de RFC 4035 §5, soporte de NSEC3 y SHA-2, y tratamiento de las consideraciones de RFC 6840 §4.

Después delimita el alcance. La perspectiva primaria debe validar DNSSEC en todas las consultas vinculadas al control del dominio y a CAA. Los métodos por correo que todavía permanecen tienen una excepción parcial: CNAME, CAA y TXT para obtener el Authorization Domain Name siguen bajo obligación; otras consultas reciben lenguaje SHOULD. Para los demás métodos y CAA, una política local no puede desactivar la validación. Un error como SERVFAIL en la primaria no se convierte en permiso de emitir dentro de ese límite.

El apartado remoto emplea MAY. Cada perspectiva remota que participe en MPIC puede efectuar validación DNSSEC hasta el ancla raíz de IANA. Puede hacerlo o no hacerlo sin que esa elección, por sí sola, decida si la observación cuenta como corroboración.

Así, el campo DNSSEC correcto no es una prueba completa. Debe responder: ¿quién hizo la consulta?, ¿qué resolutor utilizó?, ¿era la perspectiva primaria o una remota?, ¿qué familias de consulta cubrió?, ¿qué estado obtuvo?, ¿qué hizo el sistema ante el error?, ¿a qué emisión quedó unido?

Una matriz evita convertir dos controles en uno

La moción SC067v3 creó MPIC para dificultar que un ataque BGP de prefijo igualmente específico engañe el proceso de validación. El mecanismo corrobora desde perspectivas remotas la determinación que hizo la primaria antes de emitir.

DNSSEC evalúa la autenticidad criptográfica de datos DNS y de las negaciones firmadas. El RFC 4035 permite que el resolutor clasifique el resultado como Secure, Insecure, Bogus o Indeterminate. Ninguno de esos estados dice si el punto estaba en el cuórum, en qué región operaba o qué decisión tomó la CA.

MPIC aporta diversidad de observación. Desde el 15 de junio de 2026, el calendario reproducido en SC100 exige al menos cuatro perspectivas remotas, el cuórum correspondiente y corroboradores en al menos dos regiones de servicio RIR. El 15 de diciembre el mínimo sube a cinco. No dice que haya cuatro o cinco validadores DNSSEC obligatorios.

La representación correcta es una matriz, no un único indicador:

Perspectiva Papel Observación DCV/CAA DNSSEC efectuado Estado DNSSEC Cuenta en cuórum
P-0 Primaria resultado base obligatorio estado RFC 4035 base a corroborar
R-1…R-n Remota corroboración/no corroboración sí o no permitido estado si se hizo según regla MPIC

La tabla es conceptual, no un formato impuesto por el Foro. Su ventaja es evitar que un cuórum verde sea leído como DNSSEC en todas partes y que un MAY no ejercido se anote falsamente como Insecure. La ausencia de ejecución y el estado protocolario inseguro son hechos distintos.

La discusión fue sobre suficiencia, no sobre conservarlo todo

SC096 había retirado la verificación DNSSEC del registro amplio exigido a DCV y CAA. El razonamiento publicado mencionaba que los resolutores no están diseñados para un registro exhaustivo y que la gestión de cambios podía confirmar la activación de los controles.

El §4.2.2.2.7 propuesto por SC100 conserva la exclusión: el conjunto completo de información de consultas DNS vinculadas a DNSSEC queda fuera del autoexamen del §8.7 y del registro del §5.4.1. Inmediatamente después, el borrador exige que la CA retenga información suficiente para verificar el cumplimiento del resto de la nueva sección consolidada.

Las actas del 16 de julio explican por qué. La cuestión pendiente era si ordenar una modalidad concreta de registro. Se optó por exigir evidencia suficiente y permitir flexibilidad técnica. La discusión se reinició con el cambio; el registro del 30 de julio señala que no llegaron comentarios adicionales antes de la votación.

Este compromiso no es un vacío. Rechaza dos extremos: una simple declaración de configuración que no se une a ninguna emisión y una traza total de DNS que almacena más de lo necesario. Corresponde a cada CA definir un conjunto mínimo capaz de contestar la proposición normativa.

El recibo de control no sustituye al recibo de emisión

Un recibo de control fija el estado aprobado de la perspectiva primaria durante un intervalo. Puede incluir:

ID de control + ID de perspectiva primaria + servicio/resolutor + versión y compilación + hash de configuración/política + versión de anclas + capacidad RFC 4035/NSEC3/SHA-2/RFC 6840 + excepciones locales + pruebas + cambio aprobado + válido desde/hasta

No es necesario publicar configuraciones sensibles. Una huella y una referencia protegida permiten revisar el artefacto bajo autorización. Este recibo demuestra capacidad e intención operativa en un periodo; no demuestra que una petición concreta pasó por ese servicio.

El recibo de emisión hace esa segunda parte:

ID de intento + certificado o precertificado + tiempo de solicitud/decisión + nombre y alcance + método de validación + alcance CAA + versión normativa + perspectiva primaria + resolutor/recibo de control + familias consultadas + estado DNSSEC + error y decisión de cierre + perspectivas remotas + marca DNSSEC por remota + estado si se hizo + región + observación y cuórum MPIC + relación con reintentos + hash del registro

Ambos recibos se unen por la identidad de la perspectiva, la identidad del control y el intervalo temporal. Si una remota no hizo DNSSEC dentro de la opción permitida, debe decir no efectuado, no inferir un estado RFC. Si lo hizo, el resultado pertenece a esa remota y no se copia desde la primaria.

Este diseño es una recomendación de Daniel Kade, no una enumeración escondida en SC100. No se atribuye a DigiCert por la afiliación del proponente, ni a Amazon o eMudhra por el respaldo, ni a los consumidores que votaron, ni a un auditor. La moción define suficiencia y deja el formato abierto.

Cinco objetos públicos no forman automáticamente una cadena

Una CP/CPS actualizada declara una práctica. Una versión de software identifica código. Una prueba comprueba un caso. Un estado Secure clasifica una observación. Un certificado constata que hubo emisión. Para demostrar el cumplimiento aún hay que mostrar que la perspectiva primaria de esa tentativa utilizó la configuración probada, cubrió las consultas requeridas, trató el error según la norma y entregó el resultado a la decisión vinculada al certificado.

La unanimidad del voto prueba acuerdo normativo entre quienes participaron. No prueba despliegue en los sistemas de cada votante. Del mismo modo, la falta de detalle público sobre una CA no prueba incumplimiento. Este artículo no identifica emisiones indebidas, envenenamiento DNS, registros ocultos ni fallos de una empresa.

La incertidumbre relevante está delimitada: el resultado de la revisión IPR, el texto final, la próxima versión publicada y la evidencia real de cada implementación. Hasta entonces, el estado verificable es borrador aprobado en votación y aún no incorporado.

Fuentes