Partager via

Exigences du programme - Programme racine de confiance Microsoft

  • Article

1. Introduction

Le programme de certificat racine Microsoft prend en charge la distribution de certificats racines, ce qui permet aux clients d'approuver les produits Windows. Cette page décrit les exigences générales et techniques du programme.

Remarque

2. Exigences continues du programme

Exigences d'audit

  1. Les participants au programme doivent fournir à Microsoft une preuve d’un audit qualifiant (voir https://aka.ms/auditreqs) pour chaque autorité de certification racine secondaire non contrainte, et un certificat avec signature croisée, avant d’effectuer toute opération commerciale, sur une base annuelle.
  2. Les participants au programme doivent s'assurer que toutes les autorités de certification secondaires non contraintes et les certificats avec signature croisée sont conformes aux exigences d'audit du programme.
  3. Les autorités de certification doivent divulguer publiquement tous les rapports d'audit pour les autorités de certification secondaires non contraintes.
  4. Les fournisseurs d'autorité de certification doivent s'assurer que leurs autorités de certification racine compatibles S/MIME et toutes les autorités de certification subordonnées capables de délivrer des certificats S/MIME ont été et continueront d'être auditées par rapport à la version la plus récente, au minimum, de l'un des ensembles de critères ci-dessous. Cet audit doit avoir lieu au moins une fois par an. Une première période d’audit doit débuter au plus tard le 1er septembre 2023.
    • Principes et critères WebTrust pour les autorités de certification – S/MIME
    • ETSI EN 119 411-6 LCP, NCP ou NCP+

Exigences en matière de communication et de divulgation

  1. Les participants au programme doivent fournir à Microsoft les identités d'au moins deux « Agents approuvés » devant servir de représentants pour le programme, ainsi qu'un alias d'e-mail général. Les participants au programme doivent informer Microsoft de la suppression ou de l'ajout de personnel assumant la fonction d'Agent approuvé. Les participants au programme acceptent de recevoir des notifications par e-mail, et doivent fournir à Microsoft une adresse e-mail pour la réception des avis officiels. Les participants au programme doivent accepter que les avis soient effectifs lorsque Microsoft envoie un e-mail ou une lettre officielle. Au moins un des contacts ou alias fournis doit être un canal de communication supervisé 24/7 pour les demandes de révocation ou autres situations de gestion des incidents.

  2. Le participant au programme doit divulguer sa hiérarchie d'infrastructure à clé publique complète (autorité de certification secondaire non limitée, autorités de certification racines non inscrites et avec signature croisée, autorités de certification secondaires, utilisations améliorées de la clé (EKU), contraintes de certificats) à Microsoft sur une base annuelle, y compris les certificats émis pour les autorités de certification gérées par des tierces parties externes au sein de la CCADB. Les participants au programme doivent tenir ces informations à jour dans la CCADB lorsque des changements ont lieu. Si une autorité de certification secondaire n’est pas auditée ou divulguée publiquement, elle doit être limitée au domaine.

  3. Les participants au programme doivent informer Microsoft par e-mail au moins 120 jours avant de transférer la propriété d'une autorité de certification racine ou secondaire inscrite qui est chaînée à une racine inscrite à une autre entité ou personne.

  4. Le code de raison doit être inclus dans les révocations des certificats intermédiaires. Les autorités de certification doivent mettre à jour la CCADB lors de la révocation des certificats intermédiaires dans les 30 jours.

  5. Les participants au programme conviennent que Microsoft peut contacter les clients qui, d'après Microsoft, sont susceptibles d'être sensiblement impactés par la suppression prochaine d'une autorité de certification racine du programme.

Autres conditions requises

  1. Les autorités de certification commerciales ne peuvent pas inscrire dans le programme une autorité de certification racine qui est destinée à être principalement approuvée en interne au sein d'une organisation (par exemple les autorités de certification d'entreprise).

  2. Si une autorité de certification utilise un sous-traitant pour exploiter tout aspect de son activité, elle assume la responsabilité des opérations commerciales du sous-traitant.

  3. Si Microsoft, à sa seule discrétion, identifie un certificat dont l'utilisation ou les attributs sont jugés contraires aux objectifs du programme Trusted Root, Microsoft en informera l'autorité de certification responsable et lui demandera de révoquer le certificat. L'autorité de certification doit révoquer le certificat ou demander une exception à Microsoft dans les 24 heures qui suivent la réception de la notification de Microsoft. Microsoft examinera les documents soumis et informera l'autorité de certification quant à sa décision finale d'accorder ou de refuser l'exception à sa seule discrétion. Dans le cas où Microsoft n’accorde pas l’exception, l’autorité de certification doit révoquer le certificat dans les 24 heures suivant le refus de l’exception.

3. Exigences techniques du programme

Toutes les autorités de certification du programme doivent respecter les exigences techniques du programme. Si Microsoft détermine qu’une autorité de certification n’est pas en conformité avec les exigences ci-dessous, Microsoft exclut cette autorité de certification du programme.

A. Exigences concernant la racine

  1. Les certificats racines doivent être des certificats x.509 v3.
    1. L'attribut CN doit identifier l'éditeur et doit être unique.
    2. L'attribut CN doit être dans une langue correspondant au marché de l'autorité de certification, et être lisible par un client type sur ce marché.
    3. Extension de contraintes de base : doit être cA=true.
    4. L'extension d'utilisation de la clé DOIT être présente et DOIT être marquée comme critique. Les positions de bits pour keyCertSign et cRLSign DOIVENT être définies. Si la clé privée de l'autorité de certification racine est utilisée pour la signature des réponses OCSP, le bit digitalSignature DOIT être défini.
      • Les tailles de clé racine doivent répondre aux exigences détaillées dans « Exigences relatives aux clés ».
  2. Les certificats à ajouter au magasin racine approuvé DOIVENT être des certificats racines auto-signés.
  3. Les autorités de certification racine nouvellement créées doivent être valides pendant un minimum de huit ans et un maximum de 25 ans à compter de la date de soumission.
  4. Les autorités de certification racines participantes ne peuvent pas émettre de nouveaux certificats RSA 1024 bits à partir des racines couvertes par ces exigences.
  5. Tous les certificats d'entité finale doivent contenir une extension AIA avec une URL OCSP valide. Ces certificats peuvent également contenir une extension CDP qui contient une URL de liste de révocation de certificats valide. Tous les autres types de certificats doivent contenir soit une extension AIA avec une URL OCSP, soit une extension CDP avec une URL de liste de révocation de certificats valide
  6. Les clés privées et les noms d'objets doivent être uniques à chaque certificat racine ; la réutilisation des clés privées ou des noms d'objets dans les certificats racines suivants par la même autorité de certification peut entraîner des problèmes de chaînage de certificats inattendus. Les autorités de certification doivent générer une nouvelle clé et appliquer un nouveau nom d'objet lors de la génération d'un nouveau certificat racine avant la distribution par Microsoft.
  7. Les autorités de certification gouvernementales doivent limiter l'authentification du serveur aux domaines de premier niveau émis par le gouvernement, et peuvent émettre uniquement d'autres certificats vers les codes de pays ISO3166 sur lesquels le pays a un contrôle souverain (voir la section III https://aka.ms/auditreqs pour connaître la définition du terme « autorité de certification gouvernementale »). Ces domaines de premier niveau émis par le gouvernement sont référencés dans le contrat respectif de chaque autorité de certification.
  8. Les certificats d'autorité de certification émettrice qui chaînent à une autorité de certification racine participante doivent séparer les usages Authentification du serveur, S/MIME, Signature du code et Horodatage. Cela signifie qu'une seule autorité de certification émettrice ne doit pas combiner l'authentification du serveur avec S/MIME, la signature de code ou l'horodatage EKU. Un intermédiaire distinct doit être utilisé pour chaque cas d'usage.
  9. Les certificats d'entité finale doivent remplir les conditions requises en matière de type d'algorithme et de taille de clé pour les certificats d'abonné mentionnés dans l'Annexe A des conditions de base de référence du forum CAB qui se trouvent à l'adresse https://cabforum.org/baseline-requirements-documents/.
  10. Les autorités de certification doivent déclarer l’un des OID d’Azure Policy suivants dans leur certificat d’entité finale d’extension de stratégie de certification.
    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. Signature de code Non-EV 2.23.140.1.4.1.
  11. À partir d'août 2024, tous les OID SSL EV personnalisés gérés par le programme Trusted Root et nos outils respectifs seront supprimés et remplacés par des OID SSL EV conformes au CA/B Forum (2.23.140.1.1). L'équipe Microsoft Edge mettra en œuvre des vérifications de l'OID SSL EV (2.23.140.1.1) dans le navigateur, de sorte que les autres OID SSL EV ne seront plus acceptés pour s'aligner sur Edge et éviter les incompatibilités.
  12. Les autorités de certification ne peuvent pas avoir plus de 2 OID appliqués à leur certificat racine.
  13. Les certificats d'entité finale qui incluent une extension de contraintes de base conformément à la norme IETF RFC 5280 doivent avoir le champ cA défini sur FALSE, et le champ pathLenConstraint doit être absent.
  14. Une autorité de certification doit techniquement contraindre un répondeur OCSP de telle sorte que la seule EKU autorisée soit la signature OCSP.
  15. Une autorité de certification doit être en mesure de révoquer un certificat à une date spécifique, conformément à la requête de Microsoft.

B. Exigences relatives à la signature

Algorithme Tous usages à l'exception de Signature du code et Horodatage Usages Signature du code et Horodatage
Algorithmes Digest SHA2 (SHA256, SHA384, SHA512) SHA2 (SHA256, SHA384, SHA512)
RSA 2 048 4096 (nouvelles racines uniquement)
ECC / ECDSA NIST P-256, P-384, P-521 NIST P-256, P-384, P-521

À noter : Les signatures utilisant la cryptographie à courbe elliptique (ECC), telles que ECDSA, ne sont pas prises en charge dans Windows et les dernières fonctionnalités de sécurité Windows. Les utilisateurs utilisant ces algorithmes et certificats seront confrontés à diverses erreurs et risques de sécurité potentiels. Le programme Microsoft Trusted Root recommande de ne pas émettre les certificats ECC/ECDSA aux abonnés en raison de cette incompatibilité et de ce risque connus.

C. Exigences de révocation

  1. Les autorités de certification doivent disposer d'une politique de révocation documentée et doivent avoir la capacité de révoquer tout certificat qu'elles émettent.
  2. Les autorités de certification qui émettent des certificats d'authentification de serveur doivent prendre en charge les deux exigences de répondeur OCSP suivantes :
    1. Une validité minimale de huit (8) heures ; une validité maximale de sept (7) jours.
    2. La mise à jour suivante doit être disponible au moins huit (8) heures avant l'expiration de la période actuelle. Si la validité est supérieure à 16 heures, la mise à jour suivante doit être disponible à la moitié de la période de validité.
  3. Tous les certificats émis par une autorité de certification racine doivent prendre en charge l'extension de point de distribution de liste de révocation de certificats et/ou l'AIA contenant une URL de répondeur OCSP.
  4. L'autorité de certification ne doit pas utiliser le certificat racine pour émettre des certificats d'entité finale.
  5. Si une autorité de certification émet des certificats de signature du code, elle doit utiliser une autorité Horodatage conforme à la norme RFC 3161, « Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP) ».

D. Exigences relatives aux certificats racines de signature du code

  1. Les certificats racines qui prennent en charge l'utilisation de la signature du code peuvent être supprimés de la distribution par le programme après 10 ans à compter de la date de distribution d'un certificat racine de substitution de remplacement ou plus tôt, si l'autorité de certification le demande.
  2. Les certificats racines qui restent en distribution pour prendre en charge uniquement l'usage de signature du code au-delà de la durée de vie de sécurité de l'algorithme (par exemple, RSA 1024 = 2014, RSA 2048 = 2030) peuvent être définis sur « Désactiver » dans le système d'exploitation Windows 10.
  3. À partir de février 2024, Microsoft n’acceptera ni ne reconnaîtra plus les certificats de signature de code EV, et le CCADB cessera d’accepter les audits de signature de code EV. À partir d’août 2024, tous les OID de signature de code EV seront supprimés des racines existantes dans le programme Microsoft Trusted Root, et tous les certificats de signature de code seront traités de la même manière.

E. Exigences relatives à l'utilisation améliorée de la clé (EKU)

  1. Les autorités de certification doivent fournir une justification métier pour toutes les EKU attribuées à leur certificat racine. La justification peut se présenter sous la forme de preuves publiques d'une activité en cours d'émission de certificats d'un ou plusieurs types, ou d'un plan commercial démontrant l'intention d'émettre ces certificats à court terme (dans un délai d'un an à compter de la distribution du certificat racine par le programme).

  2. Microsoft activera uniquement les EKU suivantes :

    1. Authentification du serveur =1.3.6.1.5.5.7.3.1
    2. Authentication du client =1.3.6.1.5.5.7.3.2
    3. EKU d'e-mail sécurisé =1.3.6.1.5.5.7.3.4
    4. EKU d'horodatage=1.3.6.1.5.5.7.3.8
    5. EKU de signature de document =1.3.6.1.4.1.311.10.3.12
    • Cette EKU est utilisée pour la signature de documents au sein d'Office. Elle n’est pas requise pour d’autres usages de signature de documents.

F. Exigences relatives à la signature du code Mode noyau (KMCS, Kernel Mode Code Signing) Windows 10

Windows 10 a des exigences renforcées en matière de validation des pilotes en mode noyau. Les pilotes doivent être signés à la fois par Microsoft et par un partenaire de programme à l'aide des exigences de validation étendues. Tous les développeurs qui souhaitent que leurs pilotes en mode noyau soient inclus dans Windows doivent suivre les procédures décrites par l'équipe de développement matériel Microsoft. Pour plus d’informations, consultez l’Espace partenaires pour le matériel Windows.