Compartilhar via

Requisitos do programa — Programa raiz confiável da Microsoft

  • Artigo

1. Introdução

O Programa de certificado raiz da Microsoft dá suporte à distribuição de certificados raiz, permitindo que os clientes confiem nos produtos Windows. Esta página descreve os requisitos técnicos e gerais do Programa.

Observação

2. Requisitos contínuos do programa

Requisitos da Auditoria

  1. Os participantes do programa devem fornecer evidências de uma auditoria qualificada à Microsoft (confira https://aka.ms/auditreqs) para cada raiz, AC subordinada irrestrita e certificado cruzado, antes de realizar operações comerciais e posteriormente de forma anual.
  2. Os participantes do programa devem assumir a responsabilidade de garantir que todas as ACs subordinadas e certificados cruzados não restringidos atendam aos requisitos de auditoria do programa.
  3. As ACs devem divulgar publicamente todos os relatórios de auditoria das ACs subordinadas não restringidas.
  4. Os provedores de AC precisam garantir que as ACs raiz habilitadas para S/MIME e todas as ACs subordinadas possam emitir certificados S/MIME que tenham sido e continuarão sendo auditados em relação à versão mais recente de, no mínimo, um dos conjuntos de critérios abaixo. Essa auditoria precisa ocorrer, pelo menos, uma vez por ano. É necessário que um período inicial de auditoria seja iniciado até 1º de setembro de 2023.
    • Princípios e critérios do WebTrust para autoridades de certificação – S/MIME
    • ETSI EN 119 411-6 LCP, NCP ou NCP+

Requisitos de comunicação e divulgação

  1. Os participantes do programa devem fornecer à Microsoft as identidades de pelo menos dois "agentes confiáveis" para atuar como representantes do programa e um alias de email geral. Os participantes do programa devem informar à Microsoft sobre a remoção ou adição de pessoal como agentes confiáveis. Os participantes do programa concordam em receber avisos por email e devem fornecer à Microsoft um endereço de email para receber avisos oficiais. Os participantes do programa devem concordar que o aviso começa a valer quando a Microsoft envia um email ou uma carta oficial. Pelo menos um dos contatos ou aliases fornecidos deve ser um canal de comunicações monitorado 24 horas por dia, sete dias por semana para solicitações de revogação ou outras situações de gerenciamento de incidentes.

  2. O Participante no Programa deve divulgar anualmente à Microsoft toda a sua hierarquia de PKI (autoridade de certificação subordinada não limitada, autoridades de certificação de raiz não registadas de assinatura cruzada, autoridades de certificação subordinadas, EKU, restrições de certificados), incluindo os certificados emitidos a autoridades de certificação operadas por terceiros externos no âmbito do CCADB. Os participantes do programa devem manter essas informações precisas no CCADB quando ocorrerem alterações. Se uma AC subordinada não for divulgada ou auditada publicamente, ela deverá ser restrita ao domínio.

  3. Pelo menos 120 dias antes de transferir para outra entidade ou pessoa a propriedade da AC raiz ou subordinada registrada que se encadeia a uma raiz registrada, os participantes do programa devem comunicar à Microsoft por email.

  4. O código do motivo deve ser incluído em revogações para certificados intermediários. As ACs devem atualizar o CCADB ao revogar quaisquer certificados intermediários dentro de 30 dias.

  5. Os participantes do programa concordam que a Microsoft pode entrar em contato com os clientes que ela acredita que podem ser substancialmente afetados pela remoção pendente de uma AC raiz do programa.

Outros requisitos

  1. As ACs comerciais não podem registrar uma AC raiz no programa que deva ser principalmente confiável internamente em uma organização (ou seja, ACs corporativas).

  2. Se uma AC usar um subcontratado para operar qualquer aspecto de seu negócio, ela assumirá a responsabilidade pelas operações de negócios do subcontratado.

  3. Se a Microsoft, a critério exclusivo, identificar um certificado cujo uso ou atributos sejam determinados como contrários aos objetivos do Programa Raiz Confiável, ela notificará a AC responsável e solicitará que ela revogue o certificado. A AC deve revogar o certificado ou solicitar à Microsoft uma exceção dentro de 24 horas do recebimento do aviso. A Microsoft revisará o material enviado e informará a AC sobre a decisão final de conceder ou negar a exceção a seu critério exclusivo. Caso a Microsoft não conceda a exceção, a AC deve revogar o certificado dentro de 24 horas da negação da exceção.

3. Requisitos técnicos do programa

Todas as ACs do programa devem estar em conformidade com os Requisitos técnicos do programa. Se a Microsoft determinar que uma AC não está em conformidade com os requisitos abaixo, ela excluirá essa autoridade do programa.

R. Requisitos raiz

  1. Os certificados raiz devem ser do tipo x.509 v3.
    1. O atributo CN deve identificar o distribuidor e ser exclusivo.
    2. O atributo CN deve estar em um idioma apropriado para o mercado da AC e ser legível por um cliente típico desse mercado.
    3. Extensão de restrições básicas: deve ser cA=true.
    4. A extensão de uso de chave DEVE estar presente e DEVE ser marcada como crítica. As posições de bits para KeyCertSign e cRLSign DEVEM estar definidas. Se a chave privada da AC raiz for usada para assinar respostas OCSP, o bit digitalSignature DEVERÁ estar definido.
      • Os tamanhos de chave raiz devem atender aos requisitos detalhados em "Requisitos de assinatura" abaixo.
  2. Os certificados a serem adicionados ao Armazenamento de raiz confiável DEVEM ser certificados raiz autoassinados.
  3. As ACs raiz recém-criadas devem ser válidas por, no mínimo, oito anos e, no máximo, 25 anos, a partir da data de envio.
  4. As ACs raiz participantes não podem emitir novos certificados RSA de 1.024 bits a partir de raízes cobertas por esses requisitos.
  5. Todos os certificados de CA emissores devem conter uma extensão CDP com uma CRL válida e/ou uma extensão AIA para um respondente OCSP. Um certificado de entidade final pode conter uma extensão AIA com uma URL OCSP válida e/ou uma extensão CDP apontando para um ponto de extremidade HTTP válido que contém a CRL. Se uma extensão AIA com um URL OCSP válido NÃO estiver incluída, o arquivo CRL resultante deverá ter <10 MB.
  6. Chaves privadas e nomes de entidades devem ser exclusivos por certificado raiz; a reutilização de chaves privadas ou nomes de entidades em certificados raiz subsequentes pela mesma AC pode resultar em problemas inesperados de encadeamento de certificados. As ACs devem gerar uma nova chave e aplicar um novo nome de entidade ao gerar um novo certificado raiz antes da distribuição pela Microsoft.
  7. As ACs governamentais devem restringir a autenticação de servidor aos domínios de nível superior emitidos pelo governo e só podem emitir outros certificados para os códigos de país ISO3166 para os quais o país tem controle soberano (confira a seção III de https://aka.ms/auditreqs para ver a definição de uma "AC governamental"). Esses TLDs emitidos pelo governo são mencionados nos respectivos contratos de cada AC.
  8. A emissão de certificados de AC que se encadeiam a uma AC raiz participante deve separar a Autenticação de servidor, S/MIME, Assinatura de código e usos de carimbo de data/hora. Isso significa que uma AC emissora individual não deve combinar a autenticação de servidor com o S/MIME, a assinatura de código ou o EKU de carimbo de data/hora. Um intermediário separado deve ser usado para cada caso de uso.
  9. Os certificados de entidade final devem atender aos requisitos de tipo de algoritmo e tamanho de chave para certificados de assinante listados no Apêndice A dos requisitos de linha de base do fórum CAB localizados em https://cabforum.org/baseline-requirements-documents/.
  10. As ACs devem declarar um dos OIDs de política a seguir no certificado de entidade final da extensão da Política de Certificado.
    1. DV 2.23.140.1.2.1.
    2. OV 2.23.140.1.2.2.
    3. EV 2.23.140.1.1.
    4. IV 2.23.140.1.2.3.
    5. Assinatura de código não EV 2.23.140.1.4.1.
    6. Caixa de correio S/MIME validada como legada 2.23.140.1.5.1.1.
    7. Caixa de correio S/MIME validada multiuso 2.23.140.1.5.1.2.
    8. Caixa de correio S/MIME validada estritamente 2.23.140.1.5.1.3.
    9. Organização S/MIME Legacy 2.23.140.1.5.2.1.
    10. S/MIME Validação da Organização Multiuso 2.23.140.1.5.2.2.
    11. Organização S/MIME validada estritamente 2.23.140.1.5.2.3.
    12. Legado validado pelo patrocinador do S/MIME 2.23.140.1.5.3.1.
    13. Patrocinador S/MIME validado multiuso 2.23.140.1.5.3.2.
    14. Patrocinador S/MIME validado estrito 2.23.140.1.5.3.3.
    15. Legado validado individual S/MIME 2.23.140.1.5.4.1.
    16. S/MIME Individual Validado Multiuso 2.23.140.1.5.4.2.
    17. S/MIME Individual Validado Estrito 2.23.140.1.5.4.3.
  11. A partir de agosto de 2024, todos os OIDs SSL de EV personalizados, gerenciados pelo Programa Raiz Confiável, e nossas respectivas ferramentas serão removidos e substituídos pelo OID SSL de EV compatível com o CA/B Forum (2.23.140.1.1). A equipe do Microsoft Edge implementará verificações de OID SSL de EV (2.23.140.1.1) no navegador, portanto, outros OIDs SSL de EV não serão mais aceitos para se alinhar ao Edge e evitar incompatibilidades.
  12. As ACs não podem ter mais de dois OIDs aplicados ao certificado raiz.
  13. Os certificados de entidade final que incluem uma extensão de restrições básicas de acordo com a RFC 5280 da IETF devem ter o campo cA definido como FALSE, e o campo pathLenConstraint deve estar ausente.
  14. Uma AC deve restringir tecnicamente um respondente OCSP, de modo que o único EKU permitido seja a assinatura do OCSP.
  15. Uma AC deve ser capaz de revogar um certificado para uma data específica, conforme solicitado pela Microsoft.

B. Requisitos de assinatura

Algoritmo Todos os usos, exceto para assinatura de código e carimbo de data/hora Uso de carimbo de data/hora e assinatura de código
Algoritmos de hash SHA2 (SHA256, SHA384, SHA512) SHA2 (SHA256, SHA384, SHA512)
RSA 2048 4.096 (somente novas raízes)
ECC / ECDSA NIST P-256, P-384, P-521 Sem suporte

Observe o seguinte:

  • Não há suporte para assinaturas que usam ECC (criptografia de curva elíptica), como ECDSA, no Windows e nos recursos de segurança mais recentes do Windows. Os usuários que utilizam esses algoritmos e certificados enfrentarão vários erros e possíveis riscos de segurança. O Programa Raiz Confiável da Microsoft recomenda que os certificados ECC/ECDSA não sejam emitidos aos assinantes devido a essa incompatibilidade e esse risco conhecidos.
  • A assinatura de código não dá suporte a ECC ou chaves > 4096

C. Requisitos de revogação

  1. As ACs devem ter uma política de revogação documentada e a capacidade de revogar qualquer certificado que emitirem.

  2. Requisitos do respondente OCSP: a. Validade mínima de 8 (oito) horas; Validade máxima de 7 (sete) dias; e b. A próxima atualização deve estar disponível pelo menos oito (8) horas antes da expiração do período atual. Se a validade for superior a 16 horas, a próxima atualização deverá estar disponível em 1/2 do período de validade.

  3. Recomendações de CRL quando o OCSP não está presente: a. Deve conter a extensão específica da Microsoft 1.3.6.1.4.1.311.21.4 (Próxima Publicação de CRL). b. A nova CRL deve estar disponível no próximo horário de publicação da CRL. c. O tamanho máximo do arquivo CRL (CRL completa ou CRL particionada) não deve exceder 10M.

    Observação

    O objetivo da seção 3.C.3 - Recomendações de CRL quando o OCSP não está presente é fornecer cobertura para usuários finais em casos de revogação em massa.

  4. A AC não deve usar o certificado raiz para emitir certificados de entidade final.

  5. Se uma AC emitir certificados de assinatura de código, ela deverá usar uma autoridade de carimbo de data/hora que cumpra com a RFC 3161, "TSP (Protocolo de carimbo de data/hora) da infraestrutura de chave pública X.509 da Internet".

D. Requisitos de certificado raiz de assinatura de código

  1. Os certificados raiz que dão suporte ao uso de assinatura de código podem ser removidos da distribuição pelo programa dez anos a partir da data de distribuição de um certificado raiz de substituição ou até antes, caso solicitado pela AC.
  2. Os certificados raiz que permanecem na distribuição para dar suporte apenas ao uso de assinatura de código além do tempo de vida de segurança do algoritmo (por exemplo, RSA 1024 = 2014, RSA 2048 = 2030) podem ser definidos como "disable" no sistema operacional Windows 10.
  3. Desde fevereiro de 2024, a Microsoft não aceita nem reconhece certificados de assinatura de código de EV e o CCADB deixou de aceitar auditorias de assinatura de código de EV. A partir de agosto de 2024, todos os OIDs de assinatura de código de EV serão removidos das raízes existentes no Programa Raiz Confiável da Microsoft e todos os certificados de assinatura de código serão tratados igualmente.

E. Requisitos de EKU

  1. As ACs devem fornecer uma justificativa comercial para todos os EKUs atribuídos ao próprio certificado raiz. A justificativa pode ser na forma de evidência pública de uma empresa atual de emissão de certificados de um tipo ou de vários ou um plano de negócios que demonstra uma intenção de emitir esses certificados em médio prazo (dentro de um ano da distribuição do certificado raiz pelo programa).

  2. A Microsoft habilitará apenas os seguintes EKUs:

    1. Autenticação de servidor =1.3.6.1.5.5.7.3.1
    2. Autenticação de cliente =1.3.6.1.5.5.7.3.2
    3. EKU de email seguro =1.3.6.1.5.5.7.3.4
    4. EKU de carimbo de data/hora =1.3.6.1.5.5.7.3.8
    5. EKU de assinatura de documento = 1.3.6.1.4.1.311.10.3.12
    • Esse EKU é usado para assinar documentos no Office. Ele não é necessário para outros usos de assinatura de documento.

F. Requisitos de KMCS (assinatura de código do modo kernel) do Windows 10

O Windows 10 tem requisitos elevados para validar drivers do modo kernel. Os drivers devem ser assinados pela Microsoft e por um parceiro de programa usando requisitos de validação estendida. Todos os desenvolvedores que desejem ter os próprios drivers de modo kernel incluídos no Windows deverão seguir os procedimentos descritos pela equipe de desenvolvimento de hardware da Microsoft. Para obter mais informações, confira o Partner Center para hardware do Windows.