Requisitos do programa - Microsoft Trusted Root Program

1. Introdução

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

2. Requisitos do programa contínuo

Requisitos da Auditoria

1. Os Participantes do Programa devem fornecer à Microsoft evidências de uma Auditoria Qualificada (consulte https://aka.ms/auditreqs) para cada autoridade de certificação subordinada raiz, sem restrições e certificado com assinatura cruzada, antes de realizar operações comerciais e, posteriormente, anualmente.
2. Os Participantes do Programa devem assumir a responsabilidade de garantir que todas as CAs subordinadas sem restrições e certificados assinados cruzados atendam aos Requisitos de Auditoria do Programa.
3. As autoridades competentes devem divulgar publicamente todos os relatórios de auditoria das autoridades competentes subordinadas sem restrições.
4. Os provedores de CA devem garantir que suas CAs raiz habilitadas para S/MIME e todas as CAs subordinadas capazes de emitir certificados S/MIME tenham sido e continuarão a ser auditadas em relação à versão mais recente de, no mínimo, um dos conjuntos de critérios abaixo. Esta auditoria deve ocorrer pelo menos uma vez por ano. Um período inicial de auditoria deve começar até 1º de setembro de 2023.
   
   • Princípios e Critérios WebTrust para Autoridades de Certificação – S/MIME
     
   • ETSI EN 119 411-6 LCP, NCP ou NCP+
     

Requisitos de Comunicação e Divulgação

4. Os Participantes do Programa devem fornecer à Microsoft as identidades de pelo menos dois "Agentes Confiáveis" para servir como representantes do Programa e um alias de email geral. Os Participantes do Programa devem informar a Microsoft sobre a remoção ou adição de pessoal como Agente Confiável. 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 entra em vigor quando a Microsoft envia um email ou uma carta oficial. Pelo menos um dos contactos ou pseudónimos fornecidos deve ser um canal de comunicação monitorizado 24 horas por dia, 7 dias por semana, para pedidos de revogação ou outras situações de gestão de incidentes.

5. O Participante do Programa deve divulgar sua hierarquia PKI completa (CA subordinada não limitada, CAs raiz não inscritas com assinatura cruzada, CAs subordinadas, EKUs, restrições de certificado) à Microsoft anualmente, incluindo certificados emitidos para CAs operadas por terceiros externos dentro da CCADB. Os Participantes do Programa devem manter essas informações precisas na CCADB quando ocorrerem alterações. Se uma autoridade de certificação subordinada não for divulgada ou auditada publicamente, ela deverá ter restrição de domínio.

6. Os Participantes do Programa devem informar a Microsoft por e-mail pelo menos 120 dias antes de transferir a propriedade da autoridade de certificação raiz ou subordinada inscrita que se conecta a uma raiz inscrita para outra entidade ou pessoa.

7. O código de razão deve ser incluído nas revogações de certificados intermédios. As autoridades competentes devem atualizar a CCADB quando revogarem quaisquer certificados intermédios no prazo de 30 dias.

8. Os Participantes do Programa concordam que a Microsoft pode entrar em contato com clientes que a Microsoft acredita que possam ser substancialmente afetados pela remoção pendente de uma autoridade de certificação raiz do Programa.

Outros Requisitos

9. As autoridades de certificação comerciais não podem inscrever uma autoridade de certificação raiz no programa que se destina a ser principalmente confiável internamente dentro de uma organização (ou seja, autoridades de certificação corporativas).

10. Se uma autoridade de certificação usar um subcontratado para operar qualquer aspeto de seus negócios, a autoridade de certificação assumirá a responsabilidade pelas operações comerciais do subcontratado.

11. Se a Microsoft, a seu exclusivo critério, identificar um certificado cujo uso ou atributos sejam considerados contrários aos objetivos do Programa Raiz Confiável, a Microsoft notificará a autoridade de certificação responsável e solicitará que ela revogue o certificado. A autoridade de certificação deve revogar o certificado ou solicitar uma exceção da Microsoft dentro de 24 horas após o recebimento do aviso da Microsoft. A Microsoft analisará o material enviado e informará a autoridade de certificação de sua decisão final de conceder ou negar a exceção a seu exclusivo critério. Caso a Microsoft não conceda a exceção, a autoridade de certificação deve revogar o certificado dentro de 24 horas após a exceção ser negada.

3. Requisitos técnicos do programa

Todas as autoridades de certificação do Programa devem estar em conformidade com os Requisitos Técnicos do Programa. Se a Microsoft determinar que uma autoridade de certificação não está em conformidade com os requisitos abaixo, a Microsoft excluirá essa autoridade de certificação do Programa.

A. Requisitos raiz

1. Os certificados raiz devem ser certificados x.509 v3.
   1. O atributo CN deve identificar o editor e deve ser exclusivo.
   2. O atributo NC deve estar numa linguagem adequada ao mercado da AC e legível por um cliente típico nesse 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 bit para KeyCertSign e cRLSign DEVEM ser definidas. Se a chave privada da autoridade de certificação raiz for usada para assinar respostas OCSP, o bit digitalSignature DEVE ser definido.
      • Os tamanhos de chave raiz devem atender aos requisitos detalhados em "Requisitos de assinatura" abaixo.
2. Os certificados a serem adicionados ao Armazenamento Raiz Confiável DEVEM ser certificados raiz autoassinados.
3. As autoridades de certificação raiz recém-cunhadas devem ser válidas por um período mínimo de oito anos, e máximo de 25 anos, a partir da data de envio.
4. As autoridades de certificação raiz participantes não podem emitir novos certificados RSA de 1024 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 contendo a CRL. Se uma extensão AIA com uma URL OCSP válida NÃO estiver incluída, o arquivo CRL resultante deverá ser <de 10MB.
6. As chaves privadas e os nomes das entidades devem ser exclusivos por certificado raiz; a reutilização de chaves privadas ou nomes de assunto em certificados raiz subsequentes pela mesma autoridade de certificação pode resultar em problemas inesperados de encadeamento de certificados. As autoridades de certificação 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 autoridades de certificação governamentais devem restringir a autenticação do servidor a domínios de nível superior emitidos pelo governo e só podem emitir outros certificados para os códigos de país ISO3166 sobre os quais o país tem controle soberano (consulte https://aka.ms/auditreqs a seção III para a definição de "autoridade de certificação governamental"). Estes TLD emitidos pelo governo são referidos nos respetivos contratos de cada AC.
8. A emissão de certificados de CA que são encadeados a uma CA raiz participante deve separar os usos de Autenticação de Servidor, S/MIME, Assinatura de Código e Carimbo de Data/Hora. Isso significa que uma única autoridade de certificação emissora não deve combinar a autenticação do servidor com S/MIME, assinatura de código ou EKU de carimbo de data/hora. Deve ser utilizado um produto intermédio separado para cada caso de utilização.
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 autoridades de certificação devem declarar um dos seguintes OIDs de política em seu certificado de entidade final de extensão de 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 herdada 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. Legado validado pela organização S/MIME 2.23.140.1.5.2.1.
    10. Organização S/MIME Multiusos Validados 2.23.140.1.5.2.2.
    11. Organização S/MIME Validada Estrita 2.23.140.1.5.2.3.
    12. Legado validado pelo patrocinador S/MIME 2.23.140.1.5.3.1.
    13. Patrocinador S/MIME Multiusos Validados 2.23.140.1.5.3.2.
    14. S/MIME Patrocinador 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 Multiusos Validados Individual 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 EV SSL personalizados gerenciados pelo Trusted Root Program e nossas respetivas ferramentas serão removidos e substituídos por EV SSL OID compatível com CA/B Forum (2.23.140.1.1). A equipe do Microsoft Edge implementará verificações para EV SSL OID (2.23.140.1.1) no navegador, para que outros EV SSL OIDs não sejam mais aceitos para se alinhar com o Edge e evitar incompatibilidades.
12. As autoridades de certificação não podem ter mais de 2 OIDs aplicados ao seu certificado raiz.
13. Os certificados de entidade final que incluem uma extensão Basic Constraints de acordo com IETF RFC 5280 devem ter o campo cA definido como FALSE e o campo pathLenConstraint deve estar ausente.
14. Uma autoridade de certificação deve restringir tecnicamente um respondente OCSP de modo que o único EKU permitido seja a assinatura OCSP.
15. Uma autoridade de certificação deve ser capaz de revogar um certificado para uma data específica, conforme solicitado pela Microsoft.

B. Requisitos de assinatura

Atenção:

• Assinaturas que usam criptografia de curva elíptica (ECC), como ECDSA, não são suportadas no Windows e em recursos de segurança mais recentes do Windows. Os usuários que utilizam esses algoritmos e certificados enfrentarão vários erros e potenciais riscos de segurança. O Microsoft Trusted Root Program recomenda que os certificados ECC/ECDSA não devem ser emitidos para assinantes devido a essa incompatibilidade e risco conhecidos.
• A assinatura de código não suporta ECC ou chaves > 4096

C. Requisitos de revogação

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

2. Requisitos de resposta 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 do período atual expirar. Se a validade for superior a 16 horas, a próxima atualização deve estar disponível em 1/2 do período de validade.

3. Recomendações de LCR quando a OCSP não está presente: a. Deve conter a extensão específica da Microsoft 1.3.6.1.4.1.311.21.4 (Next CRL Publish). 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.

   Nota

   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 autoridade de certificação não deve usar o certificado raiz para emitir certificados de entidade final.

5. Se uma autoridade de certificação emitir certificados de assinatura de código, ela deverá usar uma autoridade de carimbo de data/hora que esteja em conformidade com a RFC 3161, "Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)".

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

1. Os certificados raiz que suportam o uso de assinatura de código podem ser removidos da distribuição pelo Programa 10 anos a partir da data de distribuição de um certificado raiz de substituição ou antes, se solicitado pela autoridade de certificação.
2. Os certificados raiz que permanecem em distribuição para suportar apenas o 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 'desabilitar' no sistema operacional Windows 10.
3. A partir de fevereiro de 2024, a Microsoft não aceitará mais nem reconhecerá Certificados de Assinatura de Código EV e a CCADB deixará de aceitar Auditorias de Assinatura de Código EV. A partir de agosto de 2024, todos os OIDs de Assinatura de Código 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 do EKU

1. As autoridades de certificação devem fornecer uma justificativa comercial para todos os EKUs atribuídos ao seu certificado raiz. A justificação pode assumir a forma de provas públicas de uma atividade atual de emissão de certificados de um tipo ou tipos, ou de um plano de negócios que demonstre a intenção de emitir esses certificados a curto prazo (no prazo de um ano após a distribuição de certificados raiz pelo Programa).

2. A Microsoft habilitará apenas os seguintes EKUs:

   1. Autenticação do 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. E-mail seguro EKU=1.3.6.1.5.5.7.3.4
   4. Carimbo de data/hora EKU=1.3.6.1.5.5.7.3.8
   5. Assinatura de documento EKU=1.3.6.1.4.1.311.10.3.12
   • Este EKU é usado para assinar documentos dentro do Office. Não é necessário para outros usos de assinatura de documentos.

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

O Windows 10 aumentou os requisitos para validar drivers de modo kernel. Os drivers devem ser assinados pela Microsoft e por um parceiro do Programa usando os requisitos de Validação Estendida. Todos os desenvolvedores que desejam ter seus drivers de modo kernel incluídos no Windows devem seguir os procedimentos descritos pela Equipe de Desenvolvimento de Hardware da Microsoft. Para obter mais informações, consulte o Partner Center for Windows Hardware.