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.

Notes

2. Exigences continues du programme

Exigences d’audit

  1. Les participants au programme doivent fournir à Microsoft une preuve d’un audit qualifié (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, et par la suite 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.

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 contrainte 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 déterminés à être contraires aux objectifs du programme racine approuvé, Microsoft informe l’autorité de certification responsable et demande qu’elle révoque 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 exclura cette autorité de certification du programme.

R. 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 respecter les exigences décrites dans la section « Spécifications de clé ».
  2. Les certificats à ajouter au magasin racine approuvé DOIVENT être des certificats racines auto-signés.
  3. Les autorités de certification racines nouvellement émises doivent être valides pour 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 restreindre l’authentification du serveur aux domaines de niveau supérieur émis par le gouvernement et peuvent émettre uniquement d’autres certificats aux codes de pays ISO3166 sur lesquels le pays a un contrôle souverain (voir https://aka.ms/auditreqs la section III pour la définition d’une « 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 même autorité de certification émettrice ne doit pas combiner l’authentification du serveur avec l’EKU d’horodatage, S/MIME ou signature du code. Un intermédiaire distinct doit être utilisé pour chaque cas d’usage.
  9. Les certificats d’entité de bout en bout doivent respecter les exigences relatives au type d’algorithme et à la taille de clé des certificats Abonnés répertoriés dans l’annexe A des exigences de base du forum CAB situées à l’adresse https://cabforum.org/baseline-requirements-documents/suivante .
  10. Les autorités de certification doivent déclarer l’un des OID de stratégie suivants dans leur certificat d’entité finale d’extension de stratégie de certificat :
    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 du code EV 2.23.140.1.3
    6. Signature du code non-EV 2.23.140.1.4.1
  11. 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.
  12. Une autorité de certification doit techniquement contraindre un répondeur OCSP de telle sorte que la seule EKU autorisée soit la signature OCSP.
  13. 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

Algorithm 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

C. Exigences de révocation

  1. L’autorité de certification doit avoir une stratégie de révocation documentée, et doit être en mesure de révoquer les certificats qu’elle émet.
  2. Les autorités de certification qui émettent des certificats d’authentification de serveur doivent prendre en charge les exigences suivantes en matière de répondeur OCSP :
    1. Validité minimale de huit (8) heures ; Validité maximale de sept (7) jours ; et
    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 la signature de code au-delà de leur durée de vie de sécurité d’algorithme (par exemple RSA 1024 = 2014, RSA 2048 = 2030) peuvent être définis sur « désactiver » dans le système d’exploitation Windows 10.

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