- Crece la polémica por el posible efecto inhibidor sobre el debate público en WebPKI, luego de que Brian Holland, responsable legal de Sectigo, publicara una carta legal que recibió de Wilson Sonsini, representante legal de DigiCert
- DigiCert explicó inicialmente que la medida respondía a preocupaciones por declaraciones engañosas de un competidor y por un posible abuso del foro, pero luego reconoció que enviar una C&D fue inapropiado
- El contexto de la discusión incluía una TRO relacionada con el incidente de revocación masiva de certificados de DigiCert; DigiCert explicó que la TRO afectó solo a 1 certificado y que constaba en registros públicos
- La comunidad y el Chrome Root Program consideraron que las acciones que inhiben la participación en WebPKI no se alinean con los valores centrales del ecosistema, y DigiCert finalmente presentó un informe de incidente y medidas para evitar recurrencias
- DigiCert se comprometió a tratar en Bugzilla, y no por canales legales, los asuntos técnicos y de política de incidentes activos en Bugzilla; cuando sea necesaria una acción legal, aplicará revisión ejecutiva y aviso público, y operará un programa de ombudsman
La carta C&D de DigiCert publicada por Sectigo
- Brian Holland señaló que DigiCert había dicho en un comentario anterior de Bugzilla que “no usó a su equipo legal como escudo para evadir responsabilidad”, pero que en realidad Sectigo recibió una carta de Wilson Sonsini, representante legal de DigiCert, sobre declaraciones de Sectigo
- La carta cuestionaba declaraciones realizadas en Bugzilla por Tim Callan, Chief Compliance Officer de Sectigo, y exigía que Sectigo se asegurara de que “las declaraciones del Sr. Callan no continuaran ni fueran repetidas por otros miembros de la organización Sectigo”
- La carta mencionaba la Lanham Act, prácticas comerciales engañosas, menoscabo corporativo e interferencia ilícita, e incluía texto indicando que DigiCert podría iniciar acciones legales
- En su respuesta del 10 de diciembre de 2024, Holland refutó esto diciendo que las declaraciones cuestionadas eran preguntas u opiniones, orientadas a facilitar una discusión importante para WebPKI, por lo que no podían servir de base para una demanda legal
- Sectigo consideró que las amenazas legales que inhiben la supervisión y el debate sobre prácticas públicas de las CA no son compatibles con la cultura de análisis post mortem transparente exigida por las directrices de reporte de incidentes de CCADB
Respuesta inicial de DigiCert y reacción de la comunidad
- DigiCert respondió que apoya los ideales de Bugzilla y de la comunidad de CA, y que la carta buscaba preservar un diálogo abierto y honesto
- También expresó preocupación de que, tras el distrust de Entrust, algunos participantes estuvieran publicando en Bugzilla información engañosa o verdades a medias para inclinar negativamente la opinión pública y mantener bugs abiertos más tiempo del necesario
- Explicó que, después de la respuesta de Sectigo, no tomó medidas ni emitió respuestas adicionales, y pensó que el asunto estaba cerrado hasta que Sectigo volvió a hacerlo público
- Varios participantes de la comunidad criticaron que la carta completa solo podía leerse como una amenaza legal, y pidieron que DigiCert reconociera parte del error y mejorara su comunicación interna
- Mozilla afirmó que los procedimientos transparentes y basados en la comunidad son un principio central, y que las acciones que inhiben la participación en debates, sean públicas o privadas, causan un daño profundo a la comunidad
Si fue un incidente y la intervención del Chrome Root Program
- DigiCert solicitó inicialmente cerrar el bug, argumentando que el asunto no era una acusación de incumplimiento de requisitos de compliance
- Un participante de la comunidad citó la Chrome Root Program Policy para señalar que también pueden considerarse incidentes las situaciones que puedan afectar la integridad, confiabilidad o compatibilidad de un Chrome Root Program Participant
- El Chrome Root Program consideró que el feedback de la comunidad mostraba una fuerte demanda por conocer qué esfuerzos haría DigiCert para recuperar la confianza y la buena fe
- Concluyó que sería más efectivo que DigiCert abordara directamente las preocupaciones de la comunidad dentro de esta discusión de Bugzilla, en lugar de abrir un informe de incidente separado en CCADB
- DigiCert luego aceptó que esta discusión era una forma efectiva de abordar las preocupaciones de la comunidad y dijo que respondería preguntas adicionales
Reconocimiento de DigiCert e informe de incidente
- DigiCert señaló que inicialmente vio la carta como una respuesta a declaraciones engañosas de un competidor, pero luego reconoció que esa carta no se alineaba con la transparencia ni con los mejores intereses de la comunidad
- Indicó que un mejor camino habría sido usar el código de conducta del foro Bugzilla y las pautas de participación de la comunidad, y que, si pudiera volver a noviembre de 2024, no enviaría la misma carta
- Posteriormente, DigiCert presentó un Full Incident Report que catalogó como incidente el envío de la C&D a Sectigo por parte de su representante legal el 11 de noviembre de 2024
- El informe reconoció que, debido a que la C&D se superponía estrechamente con la discusión en Bugzilla, podía inhibir el debate público, y que la perceived misinformation habría sido mejor corregirla directamente en el contexto público de Bugzilla
- DigiCert explicitó que la carta original era una “amenaza de considerar acciones legales con base en las declaraciones de Tim Callan”, aunque afirmó que, en esa situación, la C&D no fue una respuesta adecuada
Factores señalados como causa
- DigiCert citó como primer factor contribuyente la novedad de la TRO
- Explicó que el incidente de revocación masiva de Bugzilla 1910805 fue significativo para DigiCert, y que el sector reafirmó que no había excepciones a los plazos de revocación
- Señaló que durante ese proceso de revocación se encontró con varias alegaciones de motivos de excepción, incluida la TRO, y que, aunque la TRO solo tuvo un rol limitado en la revocación, la divulgó por transparencia
- El segundo factor contribuyente fue la relación competitiva
- DigiCert y Sectigo son competidores directos, y DigiCert consideró que la participación en Bugzilla de personas de una CA públicamente confiable podía generar tensiones competitivas
- Explicó que 18 de los 24 comentarios de Tim Callan en Bugzilla estaban dirigidos a bugs de DigiCert, y que lo interpretó en un contexto de sensibilidad competitiva
- Indicó que, tras el incidente de revocación masiva, renunció el ejecutivo a cargo de compliance y estándares, lo que alteró los flujos de trabajo habituales de compliance y los procesos de aprobación
- En respuestas posteriores, explicó que el equipo Legal discutió el envío de la C&D con el equipo de Standards/Compliance, y que miembros de ese equipo expresaron preocupaciones, pero Legal decidió enviarla pese a la oposición interna
Medidas para evitar recurrencias
- DigiCert indicó en el informe de incidente y en el resumen de cierre que completó cuatro medidas
-
Technical-First Dispute Resolution
- Durante el reporte de incidentes, los problemas técnicos, expresiones engañosas y preocupaciones sobre incumplimientos de políticas relacionadas con compliance se tratarán en el Bugzilla correspondiente, no por canales legales
- Si se requiere una acción legal relacionada con un incidente activo, esa decisión y la acción se divulgarán en el Bugzilla relacionado
-
Community Transparency Pledge
- Las comunicaciones relacionadas con incidentes se gestionarán públicamente en foros comunitarios como MDSP, CCADB, CA/B Forum y Bugzilla para asegurar trazabilidad
- Los contactos con autores de comentarios también se documentarán y publicarán según el contexto del incidente, para que no parezcan represalias ni acciones sorpresivas
-
Legal Review Gate
- Las acciones legales que se crucen con incidentes pasarán por revisión y aprobación a nivel ejecutivo, e incluirán un análisis de por qué dicha acción legal es adecuada
- Si no es posible emitir un aviso público inmediato, se notificará de forma privada al root program y luego se proporcionará un seguimiento público
-
Ombudsperson Role for WebPKI Concerns
- DigiCert creará un procedimiento interno de ombudsman para plantear de forma privada preocupaciones sobre equidad, apertura y posibles efectos inhibidores en WebPKI
- Más tarde, Don Sheehy, una persona externa e independiente, se sumó al equipo de ombudsman para apoyar cuando sea necesario
Programa de ombudsman y debates posteriores
- DigiCert anunció inicialmente que el equipo de ombudsman estaría compuesto por representantes de Program Management, Compliance y Legal, y que se lo podría contactar en
transparency@digicert.com - Participantes de la comunidad cuestionaron si un ombudsman integrado solo por personal interno era suficientemente independiente, y DigiCert dijo que consideraría incluir a miembros externos de la comunidad o personas independientes
- DigiCert publicó cómo operará el procedimiento de ombudsman
- Las presentaciones pueden hacerse mediante
transparency@digicert.comodigicert.com/transparencyform - El proceso incluye acuse de recibo, asignación de número de caso, clasificación y enrutamiento, investigación, actualizaciones cada 7 días y elaboración de un informe
- Se permiten presentaciones anónimas, pero si se requiere verificación adicional y no hay datos de contacto, el caso puede cerrarse de inmediato
- Las presentaciones pueden hacerse mediante
- DigiCert citó como referencia la tesis doctoral de Frank Fowlie sobre el ICANN Ombudsman, y explicó que operará el programa con un enfoque de mejora continua
- Algunos participantes de la comunidad se opusieron a la visión de DigiCert de que todas las CA necesitan un ombudsman, y sostuvieron que sería mejor para la confianza en WebPKI sancionar con más fuerza a las CA que usen amenazas legales
Resumen de cierre y estado
- El resumen final de cierre de DigiCert señala que, el 11 de noviembre de 2024, un estudio jurídico contratado por DigiCert envió una C&D a Sectigo, y que DigiCert no consideró suficientemente el impacto que la C&D podía tener sobre las comunicaciones en Bugzilla y otros foros
- La causa del incidente se resumió como perceived misinformation sobre la TRO, relación competitiva y una reacción excesiva
- DigiCert presentó como remediation una disculpa formal a Sectigo y a la comunidad WebPKI más amplia, el programa de ombudsman, la incorporación de un miembro independiente y un protocolo de revisión de comunicaciones legales
- Prometió que, en el futuro, durante incidentes activos, los asuntos técnicos, de malentendidos o de política se tratarán en el Bugzilla correspondiente, y que, si determina que es necesario usar canales legales en relación con un incidente activo, divulgará esa decisión y las acciones en el Bugzilla relacionado
- Finalmente se publicó una final call solicitando comentarios o preguntas adicionales de la comunidad, con cierre previsto alrededor del 17 de septiembre de 2025
1 comentarios
Opiniones de Hacker News
En resumen, DigiCert ha retrasado varias veces la revocación de certificados más allá de lo permitido por los Baseline Requirements, y los casos recientes son https://bugzilla.mozilla.org/show_bug.cgi?id=1896053 y https://bugzilla.mozilla.org/show_bug.cgi?id=1910805
El primero parece haber retrasado la revocación para apaciguar a un cliente específico, y el segundo fue un caso en el que no pudo revocar a tiempo por una orden de restricción temporal (TRO)
Tim Callan, de Sectigo, criticó públicamente que, en ambos casos, DigiCert no se plantó con suficiente firmeza ante sus clientes, y en particular existe la preocupación de que mecanismos como las TRO puedan usarse con más frecuencia para demorar revocaciones
Sectigo y otros actores del ecosistema WebPKI parecen querer que DigiCert comunique con absoluta claridad a sus clientes la política de revocación y garantice que los clientes realmente puedan reemplazar los certificados a tiempo
Aunque Sectigo es quien más alza la voz, no parece ser el único que exige controlar las revocaciones demoradas de DigiCert, así que escalar esto con amenazas legales es realmente inapropiado, y DigiCert podría enfrentar una reacción bastante fuerte por esta táctica
Parece que no quiere modificar sus documentos legales para impedir que los clientes emprendan acciones legales por la revocación de certificados, y hasta ahora esas acciones legales han operado a favor de DigiCert
Para una empresa cuyo negocio consiste por completo en validar nombres de compañías y gestionar procedimientos de CA, se la ve bastante pasiva a la hora de cumplir precisamente esos procedimientos
No podrá impedir que clientes técnicamente incompetentes como Alegeus Technologies LLC soliciten una TRO, pero esta no es la primera vez que no sigue el procedimiento adecuado
Intentar bloquear en tribunales una discusión negativa se ve bastante vulgar para una CA, y que DigiCert, ya objeto de sospechas y desconfianza, haga algo así parece un último intento acorralado de esquivar las críticas
A los clientes les gustará que DigiCert no les obligue a reemplazar certificados en el momento establecido, pero si algo estalla y DigiCert es eliminada de las listas de confianza, de pronto se encontrarán con la sorpresa de tener que buscar otro proveedor de certificados
A primera vista, es muy razonable
La razón por la que el drama de Web PKI siempre sorprende es que es una de las pocas áreas del mundo donde las empresas “se hacen las vivas” y, por lo general, sufren casi de inmediato una fría “rendición de cuentas”
Las distintas entidades que deciden en qué CA confiar pueden, en la práctica, desmantelar casi de inmediato cualquier negocio de CA del mundo
Si DigiCert juega este juego y pierde, sería el mayor perdedor hasta ahora y, que yo sepa, DigiCert es la CA más grande de Internet
Que la mayor CA de Internet sea eliminada de los almacenes de confianza enviaría un mensaje fuerte y también generaría un gran caos, pero no hay ningún motivo claro por el que sea imposible
Por supuesto, creo que esa posibilidad es baja, pero solo imaginar la escena en la que alguien de DigiCert que decidió que era buena idea meter al equipo legal en esto recibe la reprimenda de su vida resulta satisfactorio
Leí el hilo y no deja bien parada a DigiCert; aun así, creo que esta medida es mucho más dañina para DigiCert que cualquier cosa que haya dicho Collan
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=647959
Para un proceso de retiro de confianza de una CA de este tamaño, tendría más sentido dejar de aceptar certificados nuevos emitidos después de cierta fecha
Así los clientes existentes pueden enterarse con anticipación y recibir las malas noticias en su ciclo normal de renovación, en lugar de que todo explote de golpe mientras la persona responsable está de vacaciones
Los hilos recientes sobre DigiCert huelen sospechosamente parecido a la secuencia que llevó al caso Entrust
¿Cuánta gente, al ver otra forma en que una entidad sin rostro que ni conocía puede romper algo, terminará desactivando las actualizaciones automáticas para siempre y decidiendo por su cuenta en qué confiar?
Sin duda enviaría un mensaje fuerte, pero probablemente no el mensaje buscado
Al final, solo aumentaría la desconfianza hacia la PKI centralizada en general
Según Bugzilla, la razón real del guion bajo es permitir que servicios en los que los usuarios pueden crear registros DNS en subdominios, como los servicios de DNS dinámico, impidan el registro de subdominios que empiezan con guion bajo y así eviten la emisión de certificados no deseados.
Es el mismo papel que cumple
/.well-knownen el mecanismo acordado para cambios en sitios web, y que cumplen admin/administrator/webmaster/hostmaster/postmaster en los correos de contacto de configuración de dominios.Al usar registros DNS sin guion bajo, DigiCert rompió una suposición clave de seguridad de la que dependían esos servicios.
Por eso esto es un incidente realmente grave de seguridad y un error catastrófico de enorme escala.
A esta altura no sé si se puede confiar en los certificados de DigiCert.
El autor de ese comentario es Andrew Ayer, quien también escribe excelentes artículos sobre incidentes y procesos de las CA en su blog: https://www.agwa.name/blog/index
Siempre habrá dos versiones de la historia, pero la persona de DigiCert que introdujo el bug de validación ya renunció por ese asunto, y eso en sí mismo es extremo.
La persona de Sectigo intentaba evitar que se cerrara el bug para seguir exigiendo más respuestas sobre la capacidad general de respuesta de DigiCert, y subjetivamente lo hacía de una forma bastante áspera.
Cierto nivel de ida y vuelta es aceptable y esperable, pero si sigues presionando a una contraparte que tiene su propio equipo legal, al final esa contraparte termina conversando con legal junto a la máquina de café, y cuando legal lo revisa, pasa a ser problema de ellos.
Así que el primer principio es no mencionar siquiera la palabra legal si no quieres que llamen al equipo legal.
Esta respuesta no es más que una carta para que se echen atrás, y precisamente para eso existen los equipos legales: para hacer que las partes discutan entre sí.
Solo que en este caso terminó saliendo a la luz pública.
Entiendo la postura de que las CA no deberían asumir riesgos legales durante el proceso de discusión, pero eso choca con el hecho de que son entidades comerciales que protegen sus propios intereses.
No se pueden tener ambas cosas a la vez mientras no todas las CA sean no comerciales, e incluso si lo fueran, también hay límites.
Lo mismo con cualquiera responsable de la estrategia de la empresa.
Porque la acción del equipo legal tuvo un efecto contraproducente.
Se mantuvo como contratista y probablemente esté esperando su reincorporación.
Eso se entendió mal.
Esto es impactante.
Intentar bloquear con acoso legal las declaraciones legítimas de los colaboradores de la Web PKI invierte por completo el propósito y los objetivos de la organización, y personalmente me parece motivo para descartar de inmediato todo lo relacionado con DigiCert.
La forma histórica de tratar con una CA problemática es manejar primero el daño inmediato y luego bloquear la emisión de nuevos certificados o las renovaciones.
Hay muchas empresas legítimas que usan DigiCert, y deberían poder esperar seguir operando en el corto plazo mientras encuentran otro proveedor de certificados.
Al ver el informe original (https://bugzilla.mozilla.org/show_bug.cgi?id=1910322), se notan varias preguntas que DigiCert parece esquivar.
En los registros públicos de Alegeus Technologies LLC v. DigiCert, no se ve ningún intento de impugnar la orden judicial antes de que terminara el período de preferencia de casi 120 horas, aunque, si hubieran presentado una solicitud de ese tipo, DigiCert podría haber revocado los certificados varios días antes.
Además, otra pregunta del comment 28 era cuál era la cláusula que establecía el derecho de DigiCert a revocar los certificados de Alegeus Technologies.
DigiCert fue cambiando de posición en este punto: primero insinuó que la cláusula estaba en el sitio web, pero luego se negó a confirmar si el texto del sitio en ese momento se aplicaba a Alegeus Technologies.
Como conjetura, es posible que DigiCert les haya ofrecido condiciones especiales a Alegeus y a otros clientes, y que no haya disputado la TRO en tribunales porque no tenía base contractual para hacerlo.
También es posible que ese contrato tuviera una cláusula de confidencialidad y por eso no pudiera hablar al respecto.
Es sorprendente que el foro haya dejado cerrar este issue aunque las preguntas citadas arriba no estaban satisfechas, aunque no leí completo todo el issue enlazado, así que es posible que se hayan respondido en otra parte.
Además, la respuesta que DigiCert dio en otro thread (https://bugzilla.mozilla.org/show_bug.cgi?id=1910805#c43) parece contradecir esta conjetura.
En particular, la parte que dice: “Los TOU y el MSA de DigiCert prohibían esa acción de Alegeus, pero cuando Alegeus solicitó la TRO y el tribunal la concedió casi de inmediato, DigiCert quedó atada de manos”.
Me pregunto si el CAB Forum tendría legitimación legal para demandar a Alegeus o a ese juez por interferir con los procesos de la PKI mediante una TRO inválida.
¿Qué pasó durante los poco más de dos meses desde las fechas a las que apuntan estas cartas?
Esto contradice claramente la amenaza legal contra Sectigo.
Por eso Sectigo abrió el bug Threat of legal action para informar a la comunidad qué hizo realmente DigiCert.
Si DigiCert no hubiera hecho ese comentario, quizá Sectigo se habría quedado callada.
Las autoridades de certificación reciben una confianza enorme de todos los usuarios de Internet, lo sepan o no.
Esa confianza conlleva una responsabilidad enorme, y, tal como su nombre indica, los Baseline Requirements son el estándar mínimo que deben cumplir.
Si no pueden o no están dispuestas a revocar los certificados emitidos dentro del plazo exigido, no merecen esa confianza y deberían ser removidas.
Entiendo que la TRO impidió la revocación de unos 70 certificados y que, en ese caso, realmente no había otra cosa que pudieran hacer.
Pero las demás fallas de revocación no tienen excusa.
El bug se actualizó con la respuesta de DigiCert.
Cada quien puede sacar sus propias conclusiones, pero esta frase de DigiCert sí me hizo reír:
“De hecho, nuestra carta dirigida a usted fue coherente con nuestro deseo de fomentar un diálogo abierto y honesto”.
Incluso si tomamos al pie de la letra la descripción de las conversaciones en la carta de DigiCert, la persona de Sectigo, en el mejor de los casos, fue difícil, y en el peor, quizá estaba trolleando deliberadamente.
No creo que realmente haya sido así, pero, haciendo de abogado del diablo, se podría ver de esa forma.
Aun así, ¿cómo pensó DigiCert que la intervención del equipo legal iba a salir bien?
Sectigo no tiene nada que perder y puede obtener visibilidad haciéndolo público ante el CAB, como hizo aquí, y el CAB no va a reconciliar a las dos empresas como si fuera un consejero matrimonial.
Además, este tipo de conversación pasivo-agresiva, extremadamente cortés, de “bueno, en realidad”, ocurre en todas las discusiones de incidentes del CAB.
No entiendo por qué DigiCert se enojó tanto específicamente con este caso.
Las acciones legales de DigiCert parecen raras, y la idea de que un cliente de una empresa pueda usar el sistema legal para impedir que esa empresa cumpla sus obligaciones frente a otras entidades parece tener un problema realmente peligroso.
Pero, viendo el ida y vuelta del hilo, no se ve claramente una forma productiva de abordarlo.
Es como ver una obra de teatro en la que drones corporativos típicos y geeks típicos de IRC intercambian líneas sobre el escenario: ambos lados rondan un tema interesante, pero se golpean entre sí y nunca llegan realmente al punto central.