Envie suas dúvidas sobre esta política ao fórum de políticas de CT: ct-policy@chromium.org
Quando o certificado Transport Layer Security (TLS) de uma conexão é validado em um app que ativa a Transparência de certificado, ele é avaliado para conformidade com a política de Transparência de certificado (CT) do Android. Os certificados acompanhados de carimbos de data/hora de certificado assinado (SCTs, na sigla em inglês) que atendem a esta política são considerados compatíveis com CT.
A conformidade com a CT é alcançada por um certificado e um conjunto de SCTs acompanhantes que atendem a um conjunto de requisitos técnicos impostos por bibliotecas TLS conhecidas (incluindo o Conscrypt integrado) durante a validação do certificado, que são definidos nesta política.
Estados de registros de CT
A conformidade com a CT no Android é determinada pela avaliação de SCTs de registros da CT e pela garantia de que esses registros estão nos estados corretos no momento da verificação. O conjunto de estados possíveis em que um registro de CT pode estar é:
PendingQualifiedUsableReadOnlyRetiredRejected
Para ajudar a entender os requisitos de conformidade com a CT no Android, a definição desses estados, os requisitos de registros em cada estado e como esses estados afetam o comportamento do Android são descritos em detalhes no CT Log Lifecycle Explainer (em inglês) da documentação do Chrome.
Certificados compatíveis com CT
Um certificado TLS é compatível com a CT se for acompanhado por um conjunto de SCTs que atenda a pelo menos um dos critérios definidos mais adiante, dependendo de como as SCTs são entregues ao Android. Em apps do Android que aplicam a CT, todos os certificados TLS confiáveis publicamente precisam estar em conformidade com a CT para serem validados. No entanto, os certificados que não estão registrados na CT ou têm SCTs insuficientes não são considerados emitidos incorretamente.
Ao avaliar um certificado para conformidade com a CT, o Android considera vários fatores, incluindo quantas SCTs estão presentes, quem opera o registro da CT que emitiu a SCT e em qual estado estava o registro da CT que emitiu a SCT, tanto no momento em que o certificado está sendo validado quanto no momento em que a SCT foi criada pelo registro da CT.
Dependendo de como os SCTs são apresentados ao Android, a conformidade com o CT pode ser alcançada atendendo a um dos seguintes critérios:
SCTs incorporadas:
- Pelo menos um SCT incorporado de um registro de CT que era
Qualified,UsableouReadOnlyno momento da verificação; e - Há SCTs incorporados de pelo menos N registros de CT distintos que eram
Qualified,Usable,ReadOnlyouRetiredno momento da verificação, em que N é definido na tabela a seguir; e - Entre os SCTs que atendem ao requisito 2, pelo menos dois precisam ser emitidos por operadores de registros de CT distintos, conforme reconhecido pelo Android.
- Entre as SCTs que atendem ao requisito 2, pelo menos uma precisa ser emitida por um registro reconhecido pelo Android como compatível com a RFC 6962.
| Ciclo de vida do certificado | Número de SCTs de registros de CT distintos |
|---|---|
| <= 180 dias | 2 |
| > 180 dias | 3 |
SCTs entregues via OCSP ou TLS:
- Pelo menos duas SCTs de um registro de CT que era
Qualified,UsableouReadOnlyno momento da verificação; e - Entre os SCTs que atendem ao requisito 1, pelo menos dois precisam ser emitidos por operadores de registros de CT distintos, conforme reconhecido pelo Android.
- Entre as SCTs que atendem ao requisito 1, pelo menos uma precisa ser emitida por um registro de CT reconhecido pelo Android como compatível com a RFC6962.
Para SCTs incorporadas e entregues usando OCSP ou TLS, a exclusividade do operador de registro é definida como entradas separadas na seção de operadores da lista de registros.
Na rara situação em que um registro de CT muda de operadores durante a vida útil, os registros de CT podem conter uma lista de previous_operators, acompanhada do carimbo de data/hora final em que esse registro foi operado pelo operador anterior.
Para evitar que as mudanças no operador de registro quebrem os certificados atuais, o operador de registro de cada SCT é determinado como o operador no momento da emissão do SCT, comparando o carimbo de data/hora do SCT com os carimbos de data/hora previous_operators, se presentes.
Observações importantes
Desde que um dos critérios de conformidade com o CT acima seja atendido por alguma combinação de SCTs apresentadas no handshake, SCTs adicionais, independente do status, não vão afetar o status de conformidade com o CT de um certificado de forma positiva ou negativa.
Para contribuir com a conformidade de um certificado com a CT, um SCT precisa ter sido emitido antes do carimbo de data/hora Retired do registro, se houver.
O Android usa o SCT mais antigo entre todos os SCTs apresentados para avaliar a conformidade com o CT
em relação aos carimbos de data/hora do registro de CT Retired.
Isso explica os casos extremos em que um registro de CT é desativado durante o processo de envio de solicitações de registro de certificado.
"SCT incorporado" significa um SCT entregue usando a extensão SignedCertificateTimestampList
X.509v3 no próprio certificado. Muitos servidores TLS não são compatíveis com
OCSP Stapling ou a extensão TLS. Por isso, as CAs precisam estar preparadas para incorporar SCTs aos
certificados emitidos e garantir a validação ou o tratamento EV no Android.
Como os registros de CT são adicionados ao Android
Os critérios para que os registros de CT se tornem Qualified, bem como as circunstâncias que podem fazer com que eles se tornem Retired, podem ser encontrados na Política de registros do Chrome CT.
Tempo limite de aplicação do CT
Todos os dias, o Google publica uma nova lista de registros de CT que contém um
log_list_timestamp atualizado. Uma vez por dia, os dispositivos Android tentam fazer o download da versão mais recente dessa lista para fins de verificação. A qualquer momento, se nenhuma lista de registros estiver disponível no dispositivo ou se o carimbo de data/hora da lista de registros for mais antigo que 70 dias, a aplicação da CT será desativada.
Esse tempo limite oferece uma garantia essencial ao ecossistema de CT de que novos registros de CT podem fazer a transição com segurança para o estado "Usável" em um período fixo após se tornarem Qualified.
Lista de registros do Android
A lista de registros do Android é publicada em log_list.json, que é atualizado diariamente. Essa lista de registros é oferecida sem uma API estável, um SLA ou garantias de disponibilidade.
O Android disponibiliza a lista de registros de CT para fins de envio de certificados (como autoridades de certificação) e monitores e auditores de CT que desejam permanecer compatíveis ou investigar o conteúdo dos ecossistemas de CT e WebPKI.
A confiança não autorizada na lista de registros de CT do Android coloca em risco não apenas seus usuários, mas também os usuários do Android e o ecossistema de CT como um todo. Se você estiver pensando em adicionar a aplicação de CT ao seu app, use um mecanismo compatível com a plataforma Android.
O uso da lista de registros de CT do Android fora desta política é feito por sua conta e risco e pode resultar na quebra do aplicativo ou da biblioteca. O Android precisa poder fazer mudanças na lista de registros de CT em resposta a incidentes no ecossistema de CT para manter a segurança dos usuários do Android. O Android pode tomar medidas para garantir que as dependências de terceiros na lista de registros de CT não comprometam a capacidade do Android de responder a esses incidentes, incluindo mudanças não anunciadas na lista de registros para interromper o uso não autorizado.