Summary

  • Um Internet-Draft individual propõe /.well-known/company-certs para descobrir, por HTTPS, âncoras privadas restritas a um uso de aplicação, sem inseri-las no repositório global do sistema operacional.
  • Autenticar a origem, validar uma cadeia X.509 e preferir o valid_from mais recente não comprova quem autorizou a substituição dentro da organização. Durante a sobreposição, a confiança efetiva pode mudar antes que esse mandato fique demonstrável.
  • Daniel Kade propõe um recibo de mudança de âncora que una a época exata dos metadados, impressões antiga e nova, escopo, janela de sobreposição, autoridade aprovadora, política local, confirmação independente e reversão. É orientação editorial, não requisito do IETF.

A falha aparece numa operação normal

Uma rotação planejada já basta para expor a fronteira. A organização publica a cadeia antiga e a nova durante alguns dias, evitando que todos os clientes tenham de virar ao mesmo tempo. As duas estão dentro de seus intervalos, servem ao mesmo contexto e respeitam os domínios permitidos. O cliente escolhe a mais nova, como previsto.

Esse arranjo é útil. A origem autenticada supera o envio informal de um arquivo de CA; o escopo de aplicação é mais seguro que uma instalação global; a sobreposição protege disponibilidade. Mas o sucesso técnico prova somente qual objeto saiu do domínio e qual regra o software aplicou. Ele não identifica o dono da PKI, o responsável pelo aplicativo ou o processo que aprovou a nova âncora.

Uma âncora é uma entrada da validação, não um conteúdo neutro. Ao aceitá-la, caminhos antes recusados podem se tornar válidos no contexto delimitado. A permissão de alterar o endpoint traz, portanto, capacidade técnica de alterar quem o aplicativo reconhece como autoridade. O mandato organizacional para exercer essa capacidade precisa de prova própria.

O alcance exato da proposta

draft-doehle-company-certs-discovery-00 é um Internet-Draft individual de 22 de julho de 2026, destinado ao Standards Track. Na data de corte existe apenas a revisão -00. Não é RFC, consenso do IETF nem evidência de implantação.

O mecanismo publica JSON versionado em /.well-known/company-certs, com authority_information e trust_anchors. Cada âncora se liga a um usage_context e a uma ou mais certificate_chains. Uma cadeia pode indicar valid_from, valid_until, URL HTTPS de mesma origem, material X.509 em PEM, CRL, OCSP e impressão SHA-256.

O campo permitted_domains não pode apontar livremente: os nomes devem ser iguais a uma identidade DNS no certificado TLS validado do endpoint ou subordinados a ela. isolated_store_required declara que a âncora deve permanecer em um repositório isolado. Se o cliente não consegue cumprir o isolamento, deve rejeitar o material.

A proposta não instala a CA privada no repositório global, não substitui a Web PKI, não matricula certificados finais e não declara a CA segura para qualquer finalidade. Sua vantagem é justamente limitar a confiança a uma relação de aplicação.

HTTPS é obrigatório, mas tem uma fronteira. O controle do domínio estabelece autoridade para publicar naquela origem. O texto deixa claro que isso não atesta por si só qualidade, segurança ou confiabilidade operacional da CA. DNS, hospedagem, CDN, chave TLS, implantação, administração da CA e aceitação de risco podem pertencer a equipes distintas.

A origem não contém o organograma

O RFC 8615 organiza os URIs well-known e alerta que escrever nesse espaço pode equivaler a falar pela origem inteira. Em hospedagem compartilhada ou em permissões fragmentadas, um acesso tratado como rotineiro pode ter peso institucional inesperado.

Isso não diminui a autenticação de origem. Ela responde de onde veio a declaração. O que não responde é quem, dentro da empresa, tinha competência para autorizar a mudança. A equipe web pode implantar o arquivo; a equipe de PKI pode criar a cadeia; o dono do aplicativo define o uso; uma função de risco aprova a rotação. Resumir tudo como “a empresa publicou” apaga os repasses.

O RFC 9525 ajuda o cliente a verificar a identidade TLS contra o nome de referência pretendido. Passar nesse teste mostra que a conexão alcançou um servidor autorizado para o nome. Não transforma a sessão numa ata de aprovação interna.

Uma automação pode ser autoridade legítima, desde que seu mandato seja delimitado: quais usos pode alterar, quais impressões pode substituir, que segunda evidência exige, quanto dura a sobreposição e quem pode interrompê-la. A execução bem-sucedida de um pipeline não concede legitimidade a si mesma.

valid_from resolve ordem, não mandato

Quando mais de uma cadeia é aplicável ao mesmo uso, o rascunho manda ignorar entradas fora do intervalo e escolher a que tem o valid_from mais recente, salvo regra local diferente. É uma solução determinística para convivência, não um protocolo de aprovação.

O RFC 3339 permite representar datas de forma interoperável. Uma data bem formada não diz quem a escolheu, por que a janela foi aprovada nem se duas equipes concordaram. Um publicador legítimo, um operador equivocado ou um invasor podem escrever uma marca posterior com a mesma correção sintática.

O RFC 5280 também não valida o mandato. A construção de caminho recebe âncoras e políticas locais como premissas. Ela pode comprovar que a nova cadeia é válida sob essas premissas, mas não como a âncora entrou no conjunto.

Logo, a regra do mais recente não é o problema. O problema surge quando “cadeia escolhida conforme política” vira “mudança aprovada pela organização” num painel que não preserva a diferença.

Isolamento precisa existir fora do JSON

isolated_store_required expressa intenção, não impõe uma barreira. O cliente é responsável por saber se consegue manter o material separado. Uma auditoria não deve encerrar o teste ao encontrar true.

É necessário verificar onde a âncora foi carregada, quais APIs de validação conseguem alcançá-la e se bibliotecas comuns ampliaram o escopo. Uma refatoração pode mover a coleção específica para um cache compartilhado sem mudar um byte no endpoint.

Os domínios permitidos também dependem de execução local. O parser pode guardar o campo e o construtor de caminhos ignorá-lo. Contextos de uso podem ser misturados. O registro de governança tem de ligar a restrição declarada ao comportamento observado.

O isolamento é uma das principais promessas do mecanismo. Se a âncora escapa para o repositório geral, uma escolha de aplicação ganha um raio muito maior. Isso é mudança de autoridade, não mero detalhe técnico.

Conteúdo fresco pode carregar aprovação vencida

Os RFCs 9110 e 9111 separam semântica HTTP, frescor de cache e revalidação. O rascunho recomenda cache conservador, revalidação periódica e defesa contra metadados antigos ou repetidos; o cliente pode impor um limite local.

Esses controles mostram se a representação da origem está recente. Não renovam a autorização interna. Uma exceção de emergência pode expirar antes do cache. A aprovação pode ser retirada enquanto uma borda ainda serve a época anterior. Um JSON recém-obtido pode nunca ter sido aceito pelo proprietário do aplicativo.

A primeira recuperação é um bootstrap sensível: antes dela, o canal não fornece âncora; depois, novos caminhos podem ser aceitos. Operações devem separar adesão inicial, atualização rotineira, sobreposição, corte, retirada e reversão, em vez de tratá-las como GETs idênticos.

Consultar o endpoint também pode revelar interesse por uma organização e um uso. Cache reduz exposição e carga, mas transforma o horizonte de frescor em parte da política de confiança. O intervalo precisa refletir o prazo tolerável para corrigir uma âncora, não só custo de rede.

Status de certificado não explica troca de âncora

As cadeias podem apontar CRL ou OCSP. O RFC 6960 oferece status de certificados, controle valioso para o ciclo de vida. Ele não registra quem aprovou a entrada ou saída de uma âncora.

Uma CA nova pode emitir certificados sem revogação e ainda assim ter sido incorporada sem mandato. A antiga pode continuar criptograficamente válida depois da retirada pretendida. O status dos certificados subordinados não reconstrói a decisão nem a janela de coexistência.

Apagar o objeto não corrige instantaneamente clientes em cache, dispositivos offline, sessões duradouras ou cópias feitas fora do repositório isolado. A correção deve nomear populações, prazo máximo de propagação e evidência de fechamento.

Um recibo de mudança de âncora

A proposta de Daniel Kade é um recibo de mudança de âncora de confiança para cada transição material. Não é um novo campo obrigatório no JSON público nem uma regra atribuída ao IETF. É o elo operacional entre publicação, mandato e decisão local.

Primeiro, o recibo fixa a época: digest exato do objeto, origem, identidade de referência validada, momento da recuperação e estado de cache. Acrescenta uso, domínios e isolamento. Assim, a autorização para um digest não cobre tudo o que aquela URL vier a publicar.

Depois descreve o movimento: impressões antiga e nova, identificadores das cadeias, intervalos, janela de sobreposição e corte pretendido. Adicionar, preferir, retirar e reverter são ações distintas, mesmo que todas produzam JSON válido.

A seção de autoridade registra o papel, a política ou a automação delimitada que aprovou a ação e uma referência protegida ao registro. Não é preciso expor nomes pessoais ou atas internas no endpoint público. É preciso conseguir verificar o mandato por uma via que não dependa somente da mesma implantação.

A seção local guarda a regra usada pelo cliente, a confirmação adicional, a capacidade de isolamento, o prazo de revalidação e a resposta à indisponibilidade. O fechamento une CRL, OCSP, remoção urgente, reversão, classes de clientes e tempo máximo. O próprio recibo expira para não legitimar estados futuros.

Corroboração proporcional

Um serviço interno de baixo impacto pode aceitar origem autenticada e revisão assinada no repositório. Um sistema de pagamento, assinatura ou controle de infraestrutura pode exigir segunda chave, domínio administrativo separado ou controle duplo. O rigor deve acompanhar a consequência.

Uma segunda mensagem do mesmo usuário ou uma segunda URL na mesma CDN não cria independência real. Sistemas de PKI, manifestos assinados, registros protegidos ou chaves de hardware oferecem pontos de falha mais distintos.

O RFC 5011 é apenas uma comparação limitada. Na atualização automática de âncoras DNSSEC, ele mantém estados de inclusão, espera e remoção. Não rege Company-Certs. A lição aplicável é menor: software autorizado a mudar sua própria base de confiança precisa preservar o estado da transição, não apenas o valor atual.

Preservar verbos e limites

O Internet-Draft não precisa incorporar toda a governança corporativa. Ele já oferece origem autenticada, escopo de domínio, contexto, validade e sinal de isolamento — base melhor que enviar uma CA sem contexto ou instalá-la globalmente.

As fontes não comprovam implantação, incidente ou abuso real. O caso inicial é um teste do desenho baseado na regra de seleção durante a sobreposição.

Uma operação madura mantém os verbos separados. HTTPS autentica a recuperação. JSON representa metadados. X.509 valida um caminho a partir de entradas locais. A política do cliente escolhe. A organização autoriza. O recibo conecta esses fatos sem deixar que um deles fale em nome dos outros.

Fontes

  1. https://heng.lu/the-policy-mirror/
  2. https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
  3. https://heng.lu/on-why-btw-media-exists-and-why-reality-not-advocacy-is-the-product/
  4. https://datatracker.ietf.org/doc/html/draft-doehle-company-certs-discovery-00
  5. https://datatracker.ietf.org/doc/draft-doehle-company-certs-discovery/
  6. https://datatracker.ietf.org/doc/draft-doehle-company-certs-discovery/history/
  7. https://www.rfc-editor.org/rfc/rfc8615.html
  8. https://www.rfc-editor.org/rfc/rfc9525.html
  9. https://www.rfc-editor.org/rfc/rfc5280.html
  10. https://www.rfc-editor.org/rfc/rfc6960.html
  11. https://www.rfc-editor.org/rfc/rfc9110.html
  12. https://www.rfc-editor.org/rfc/rfc9111.html
  13. https://www.rfc-editor.org/rfc/rfc8259.html
  14. https://www.rfc-editor.org/rfc/rfc3339.html
  15. https://www.rfc-editor.org/rfc/rfc5011.html