Requisitos del programa: Programa de certificados raíz de confianza de Microsoft

1. Introducción

El Programa de certificados raíz de confianza de Microsoft admite la distribución de certificados raíz, lo que permite a los clientes confiar en los productos de Windows. En esta página se describen los requisitos generales y técnicos del programa.

Nota:

• Para información sobre las actualizaciones más recientes enviadas, consulte https://aka.ms/rootupdates.
• Agregue a esta página el marcador https://aka.ms/RootCert.

2. Continuación de los requisitos del programa

Requisitos de auditoría

1. Los participantes del programa deben proporcionar a Microsoft pruebas de una auditoría cualificada (consulte https://aka.ms/auditreqs) para cada entidad de certificación raíz subordinada sin restricciones, y un certificado con firma cruzada, antes de realizar operaciones comerciales y, a partir de entonces, de forma anual.
2. Los participantes del programa deben asumir la responsabilidad de garantizar que todas las entidades de certificación subordinadas sin restricciones y los certificados con firma cruzada cumplan los requisitos de auditoría del programa.
3. Las entidades de certificación deben revelar públicamente todos los informes de auditoría de las entidades de certificación subordinadas sin restricciones.
4. Los proveedores de CA deben asegurarse de que sus CA raíz habilitadas para S/MIME y todas las CA subordinadas capaces de emitir certificados S/MIME se hayan auditado, y se sigan auditando, con la última versión de uno de los siguientes conjuntos de criterios como mínimo. Esta auditoría debe realizarse al menos una vez al año. El período de auditoría inicial debe comenzar como muy tarde el 1 de septiembre de 2023.
   
   • Principios y criterios de WebTrust para entidades de certificación - S/MIME
     
   • ETSI EN 119 411-6 LCP, NCP o NCP+
     

Requisitos de comunicación y divulgación

4. Los participantes del programa deben proporcionar a Microsoft las identidades de al menos dos "agentes de confianza" que sirvan como representantes del programa y un alias de correo electrónico general. Los participantes del programa deben informar a Microsoft sobre la eliminación o adición de personal como agente de confianza. Los participantes del programa aceptan recibir notificaciones por correo electrónico y deben proporcionar a Microsoft una dirección de correo electrónico para recibir avisos oficiales. Los participantes del programa deben aceptar que el aviso es válido cuando Microsoft envía un correo electrónico o una carta oficial. Al menos uno de los contactos o alias proporcionados debe ser un canal de comunicaciones supervisado las 24 horas del día para las solicitudes de revocación u otras situaciones de administración de incidentes.

5. El participante del programa debe revelar a Microsoft su jerarquía de PKI completa (entidad de certificación subordinada no limitada, entidades de certificación raíz no inscritas con firma cruzada, entidades de certificación subordinadas, EKU, restricciones de certificado) cada año, incluidos los certificados emitidos a entidades de certificación operadas por terceros externos dentro de la CCADB. Los participantes del programa deben mantener esta información precisa en la CCADB cuando se produzcan cambios. Si una entidad de certificación subordinada no se revela ni audita públicamente, debe estar restringida por el dominio.

6. Los participantes del programa deben informar a Microsoft por correo electrónico al menos 120 días antes de transferir la propiedad de la entidad de certificación raíz o subordinada inscrita que se encadena a un certificado raíz inscrito en otra entidad o persona.

7. El código de motivo debe incluirse en las revocaciones de los certificados intermedios. Las entidades de certificación deben actualizar la CCADB al revocar los certificados intermedios al cabo de 30 días.

8. Los participantes del programa aceptan que Microsoft pueda ponerse en contacto con los clientes que Microsoft cree que pueden estar afectados considerablemente por la eliminación pendiente de una entidad de certificación raíz del programa.

Otros requisitos

9. Es posible que las entidades de certificación comerciales no inscriban en el programa una entidad de certificación raíz que esté diseñada para que sea de confianza internamente dentro de una organización (a saber, entidades de certificación empresariales).

10. Si una entidad de certificación usa un subcontratista para dirigir cualquier aspecto de su negocio, la entidad de certificación asumirá la responsabilidad de las operaciones comerciales del subcontratista.

11. Si Microsoft, a su entera discreción, identifica un certificado cuyo uso o atributos se determina que son contrarios a los objetivos del Programa de raíz de confianza, Microsoft lo notificará a la entidad de certificación responsable y solicitará que revoque el certificado. La entidad de certificación debe revocar el certificado o solicitar una excepción a Microsoft en un plazo de 24 horas después de recibir el aviso de Microsoft. Microsoft revisará el material enviado e informará a la entidad de certificación de su decisión final de conceder o denegar la excepción a su entera discreción. En caso de que Microsoft no conceda la excepción, la entidad de certificación debe revocar el certificado al cabo de 24 horas a partir de la denegación de la excepción.

---

3. Requisitos técnicos del programa

Todas las entidades de certificación del programa deben cumplir los requisitos técnicos del programa. Si Microsoft determina que una entidad de certificación no cumple los requisitos siguientes, Microsoft la excluirá del programa.

A Requisitos de certificado raíz

1. Los certificados raíz deben ser certificados x.509 v3.
   1. El atributo CN debe identificar el editor y debe ser único.
   2. El atributo CN debe estar en un idioma adecuado para el mercado de la entidad de certificación y ser legible para un cliente típico de ese mercado.
   3. Extensión de las restricciones básicas: debe ser cA=true.
   4. La extensión de uso de clave DEBE estar presente y DEBE marcarse como crítica. Se DEBEN establecer las posiciones de bits de KeyCertSign y cRLSign. Si se usa la clave privada de la entidad de certificación raíz para firmar respuestas de OCSP, DEBE establecerse el bit digitalSignature.
      • Los tamaños de clave raíz deben cumplir los requisitos detallados en "Requisitos de clave".
2. Los certificados que se van a agregar al almacén raíz de confianza DEBEN ser certificados raíz autofirmados.
3. Las entidades de certificación raíz recién acuñadas deben ser válidas durante ocho años como mínimo y 25 como máximo, a partir de la fecha de envío.
4. Es posible que las entidades de certificación raíz participantes no emitan nuevos certificados RSA de 1024 bits de raíces cubiertas por estos requisitos.
5. Todos los certificados de entidad final deben contener una extensión AIA con una dirección URL de OCSP válida. Estos certificados también pueden contener una extensión CDP que incluya una dirección URL de CRL válida. Todos los demás tipos de certificado deben contener una extensión AIA con una dirección URL de OCSP o una extensión CDP con una dirección URL de CRL válida.
6. Las claves privadas y los nombres de firmante deben ser únicos en cada certificado raíz; la reutilización de claves privadas o nombres de firmante en posteriores certificados raíz por la misma entidad de certificación puede dar lugar a problemas inesperados de encadenamiento de certificados. Las entidades de certificación deben generar una nueva clave y aplicar un nuevo nombre de firmante al generar un nuevo certificado raíz antes de la distribución por parte de Microsoft.
7. Las entidades de certificación gubernamentales deben restringir la autenticación de los servidores a los dominios de primer nivel emitidos por la administración pública y solo pueden emitir otros certificados a los códigos de país ISO3166 sobre los que el país tenga control soberano (consulte https://aka.ms/auditreqs, sección III para ver la definición de "entidad de certificación gubernamental"). Estos TLD emitidos por el gobierno se mencionan en el contrato respectivo de cada entidad de certificación.
8. La emisión de certificados de entidad de certificación que se encadenan a una entidad de certificación raíz participante debe separar los usos de autenticación de servidor, S/MIME, firma de código y marca de tiempo. Esto significa que una sola entidad de certificación emisora no debe combinar la autenticación de servidor con S/MIME, la firma de código o el EKU de marca de tiempo. Se debe usar un intermediario distinto para cada caso de uso.
9. Los certificados de entidad final deben cumplir los requisitos de tipo de algoritmo y tamaño de clave de los certificados de suscriptor enumerados en el Apéndice A de los requisitos de línea de base del foro de CAB que se encuentran en https://cabforum.org/baseline-requirements-documents/.
10. Las entidades de certificación deben declarar uno de los siguientes OID de directiva en su certificado de entidad final de la extensión de la directiva 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. Firma de código no EV 2.23.140.1.4.1.
11. A partir de agosto de 2024, todos los OID SSL de EV personalizados administrados por el Programa raíz de confianza y nuestras herramientas respectivas se quitarán y reemplazarán por OID SSL de EV compatibles con CA/B Forum (2.23.140.1.1). El equipo de Microsoft Edge implementará comprobaciones de OID SSL de EV (2.23.140.1.1) en el explorador, por lo que otros OID SSL de EV ya no se aceptarán para alinearse con Edge y para evitar incompatibilidades.
12. Es posible que las CA no tengan más de 2 OID aplicados a su certificado raíz.
13. Los certificados de entidad final que incluyen una extensión de restricciones básicas de acuerdo con RFC 5280 de IETF deben tener el campo cA establecido en FALSE y el campo pathLenConstraint debe estar ausente.
14. Una entidad de certificación debe restringir técnicamente un respondedor OCSP de modo que el único EKU permitido sea la firma de OCSP.
15. Una entidad de certificación debe poder revocar un certificado a una fecha específica según lo solicitado por Microsoft.

B. Requisitos de firma

Algoritmo	Todos los usos excepto la firma de código y la marca de tiempo	Uso de la firma de código y la marca de tiempo
Algoritmos de síntesis	SHA2 (SHA256, SHA384, SHA512)	SHA2 (SHA256, SHA384, SHA512)
RSA	2048	4096 (solo nuevos certificados raíz)
ECC/ECDSA	NIST P-256, P-384, P-521	NIST P-256, P-384, P-521

Nota: Las firmas que usan criptografía de curva elíptica (ECC), como ECDSA, no se admiten en Windows ni en las características de seguridad de Windows más recientes. Los usuarios que utilizan estos algoritmos y certificados se encontrarán con diversos errores y posibles riesgos de seguridad. El Programa raíz de confianza de Microsoft recomienda que no deben emitirse certificados ECC/ECDSA a los suscriptores debido a esta incompatibilidad y este riesgo conocidos.

C. Requisitos de revocación

1. Las entidades de certificación deben tener una directiva de revocación documentada y la capacidad de revocar cualquier certificado que emitan.
2. Las entidades de certificación que emiten certificados de autenticación de servidor deben cumplir ambos requisitos del respondedor OCSP a continuación:
   1. Validez mínima de ocho (8) horas; validez máxima de siete (7) días.
   2. La siguiente actualización debe estar disponible al menos ocho (8) horas antes de que expire el período actual. Si la validez es superior a 16 horas, la siguiente actualización debe estar disponible a mitad del período de validez.
3. Todos los certificados emitidos desde una entidad de certificación raíz deben admitir la extensión de punto de distribución CRL o AIA que contiene una dirección URL del respondedor OCSP.
4. La entidad de certificación no debe usar el certificado raíz para emitir certificados de entidad final.
5. Si una entidad de certificación emite certificados de firma de código, debe usar una entidad de marca de tiempo que cumpla con RFC 3161, "Protocolo de marca de tiempo (TSP) de la infraestructura de clave pública de Internet X.509".

D. Requisitos del certificado raíz de firma de código

1. Los certificados raíz que admiten el uso de firma de código pueden eliminarse de la distribución del programa 10 años a partir de la fecha de distribución de un certificado raíz de sustitución o antes, si así lo solicita la entidad de certificación.
2. Los certificados raíz que permanecen en distribución para respaldar únicamente el uso de la firma de código habiendo superado la duración de seguridad de su algoritmo (por ejemplo, RSA 1024 = 2014, RSA 2048 = 2030) se pueden establecer en "disable" en el sistema operativo Windows 10.
3. A partir de febrero de 2024, Microsoft ya no aceptará ni reconocerá certificados de firma de código EV y CCADB dejará de aceptar auditorías de firma de código EV. A partir de agosto de 2024, todos los OID de firma de código EV se quitarán de las raíces existentes en el Programa raíz de confianza de Microsoft y todos los certificados de firma de código se tratarán de la misma forma.

E. Requisitos de EKU

1. Las entidades de certificación deben proporcionar una justificación comercial de todos los EKU asignados a su certificado raíz. La justificación puede ser en forma de evidencias públicas de una actividad actual de emisión de certificados de uno o varios tipos, o un plan de negocio que demuestre una intención de emitir esos certificados a corto plazo (en un año después de la distribución de certificados raíz por parte del programa).

2. Microsoft solo permitirá los siguientes EKU:

   1. Autenticación de servidor =1.3.6.1.5.5.7.3.1
   2. Autenticación de cliente =1.3.6.1.5.5.7.3.2
   3. EKU de correo electrónico seguro =1.3.6.1.5.5.7.3.4
   4. EKU de marca de tiempo =1.3.6.1.5.5.7.3.8
   5. EKU de firma de documento = 1.3.6.1.4.1.311.10.3.12
   • Este EKU se usa para firmar documentos dentro de Office. No es necesario con otros usos de firma de documentos.

F. Requisitos de firma de código en modo kernel (KMCS) de Windows 10

Windows 10 tiene requisitos elevados para validar controladores en modo kernel. Los controladores deben estar firmados por Microsoft y un asociado del programa mediante requisitos de validación ampliados. Todos los desarrolladores que quieran incluir sus controladores en modo kernel en Windows deben seguir los procedimientos descritos por el equipo de desarrollo de hardware de Microsoft. Para obtener más información, consulte el Centro de partners para hardware de Windows.