Política de Certificado de transparencia de Android

Si tienes preguntas sobre esta política, envíalas al foro de la política de CT: ct-policy@chromium.org

Cuando se valida el certificado de seguridad de la capa de transporte (TLS) de una conexión en una app que habilita la transparencia de certificados, se evalúa el cumplimiento de la política de transparencia de certificados (CT) de Android. Se dice que los certificados que se acompañan de una marca de tiempo de certificado firmado (SCT) que cumple con esta política cumplen con la CT.

El cumplimiento de la CT se logra mediante un certificado y un conjunto de SCTs adjuntos que cumplen con un conjunto de requisitos técnicos que aplican las bibliotecas TLS populares (incluida la Conscrypt integrada de Android) durante la validación de certificados, que se definen en esta política.

Estados de registro de CT

El cumplimiento de la CT en Android se determina mediante la evaluación de los SCT de los registros de CT y la verificación de que estos registros estén en los estados correctos en el momento de la verificación. El conjunto de estados posibles en los que puede estar un registro de CT es el siguiente:

  • Pending
  • Qualified
  • Usable
  • ReadOnly
  • Retired
  • Rejected

Para ayudarte a comprender los requisitos de cumplimiento de la CT en Android, la definición de estos estados, los requisitos de los registros en cada estado, así como la forma en que estos estados afectan el comportamiento de Android, se describen en detalle en la Explicación del ciclo de vida de los registros de CT de la documentación de Chrome.

Certificados que cumplen con CT

Un certificado TLS es conforme a la CT si está acompañado de un conjunto de SCT que satisfaga al menos uno de los criterios que se definen más adelante, según la forma en que se entreguen las SCT a Android. En las apps de Android que aplican la CT, todos los certificados TLS de confianza pública deben cumplir con la CT para validarse correctamente. Sin embargo, los certificados que no se registran en la CT o que tienen SCT insuficientes no se consideran emitidos de forma incorrecta.

Cuando se evalúa un certificado para el cumplimiento de la CT, Android considera varios factores, como la cantidad de SCT presentes, quién opera el registro de CT que emitió el SCT y en qué estado se encontraba el registro de CT que emitió el SCT, tanto en el momento en que se valida el certificado como en el momento en que el registro de CT creó el SCT.

Según cómo se presenten los SCT a Android, se puede lograr el cumplimiento de la CT si se cumple uno de los siguientes criterios:

SCT incorporados:

  1. Al menos un SCT incorporado de un registro de CT que era Qualified, Usable o ReadOnly en el momento de la verificación
  2. Hay SCT incorporados de al menos N registros de CT distintos que eran Qualified, Usable, ReadOnly o Retired en el momento de la verificación, donde N se define en la siguiente tabla.
  3. Entre los SCT que cumplen con el requisito 2, al menos dos deben emitirse desde operadores de registros de CT distintos, como lo reconoce Android.
  4. Entre los SCT que satisfacen el requisito 2, al menos uno debe emitirse desde un registro que Android reconozca como conforme a la RFC 6962.
Ciclo de vida del certificado Cantidad de SCT de registros de CT distintos
<= 180 días 2
Más de 180 días 3

SCT que se entregan a través de OCSP o TLS:

  1. Al menos dos SCT de un registro de CT que era Qualified, Usable o ReadOnly en el momento de la verificación
  2. Entre los SCT que cumplen con el requisito 1, al menos dos SCT deben emitirse desde operadores de registros de CT distintos, según lo reconozca Android.
  3. Entre los SCT que satisfacen el requisito 1, al menos uno debe emitirse desde un registro de CT que Android reconozca como compatible con RFC6962.

Para las SCT incorporadas y las que se entregan con OCSP o TLS, la unicidad del operador de registro se define como tener entradas separadas dentro de la sección de operadores de log_list.json.

En el caso poco frecuente de que un registro de CT cambie de operador durante su ciclo de vida, los registros de CT contienen, de manera opcional, una lista de previous_operators, acompañada de la marca de tiempo final en la que el operador anterior operó este registro. Para evitar que los cambios en el operador de registro dañen los certificados existentes, se determina que el operador de registro de cada SCT es el operador en el momento de la emisión de la SCT comparando la marca de tiempo de la SCT con las marcas de tiempo de previous_operators, si están presentes.

Notas importantes

Siempre que una combinación de SCTs presentada en el protocolo de enlace cumpla con uno de los criterios de cumplimiento de la CT anteriores, las SCT adicionales, independientemente del estado de la SCT, no afectarán de forma positiva ni negativa el estado de cumplimiento de la CT de un certificado.

Para contribuir al cumplimiento de la CT de un certificado, se debe haber emitido una SCT antes de la marca de tiempo Retired del registro, si existe una. Android usa la SCT más antigua de todas las SCT presentadas para evaluar el cumplimiento de la CT en función de las marcas de tiempo Retired del registro de CT. Esto se debe a casos extremos en los que un registro de CT se convierte en Retirado durante el proceso de envío de solicitudes de registro de certificados.

"SCT incorporado" hace referencia a un SCT que se entrega con la extensión SignedCertificateTimestampList X.509v3 dentro del certificado. Muchos servidores TLS no admiten la unión de OCSP ni la extensión TLS, por lo que las AC deben estar preparadas para incorporar SCT en los certificados emitidos para garantizar una validación correcta o el tratamiento de EV en Android.

Cómo se agregan los registros de CT a Android

Los criterios para que los registros de CT se conviertan en Qualified, así como las circunstancias que pueden hacer que se conviertan en Retired, se pueden encontrar en la política de registro de CT de Chrome.

Tiempo de espera de la aplicación de CT

Todos los días, Google publica una nueva lista de registros de CT que contiene un log_list_timestamp actualizado. Una vez al día, los dispositivos Android intentarán descargar la versión más reciente de esta lista para verificarla. En cualquier momento, si no hay una lista de registros disponible en el dispositivo o si la marca de tiempo de la lista de registros tiene más de 70 días, se inhabilitará la aplicación forzosa de la CT. Este tiempo de espera proporciona una garantía fundamental al ecosistema de CT de que los registros de CT nuevos pueden realizar la transición de forma segura a Usable en un período fijo después de convertirse en Qualified.