Conditions requises - Programme racine de Microsoft Approuvé

1. Introduction

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

Remarque

2. Exigences du programme en continu

Exigences en matière d’audit

  1. Les participants au programme doivent fournir à Microsoft des preuves d’audit qualifié ( https://aka.ms/auditreqsvoir ) pour chaque racine, une base de données subordonnée sans contrainte et un certificat signé croisée, avant d’effectuer des opérations commerciales et ensuite sur une base annuelle.
  2. Les participants au programme doivent assumer la responsabilité de s’assurer que tous les CA subordonnés et certificats signés croiséement non soumis respectent les exigences d’audit du programme.
  3. Les membres du groupe doivent divulguer publiquement tous les rapports d’audit pour les CA subordonnés non soumis à la contrainte.

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 de confiance » pour qu’ils servent de représentants du Programme et d’un alias de courrier général. Les participants au programme doivent informer Microsoft lors de la suppression ou de l’ajout du personnel en tant qu’agent approuvé. Les participants au programme acceptent de recevoir les notifications par courrier électronique et doivent fournir à Microsoft une adresse e-mail pour recevoir les notifications officielles. Les participants au programme doivent savoir que la notification est effective lorsque Microsoft leur envoie un courrier électronique ou une lettre officielle. Au moins un des contacts ou alias fournis doit être un canal de communication contrôlé 24/24 pour les demandes de révocation ou d’autres situations de gestion des incidents.

  2. Le participant au programme doit divulguer sa hiérarchie PKI complète (autorité de certification subordonnée non limitée, CA racine non inscrite croisée, CAs subordonnées, EKUs, contraintes de certificats) à Microsoft annuellement, y compris les certificats émis à des fournisseurs de certification externes gérés par des tiers externes dans le CCADB. Les participants au programme doivent conserver ces informations exactes dans le CCADB lorsque des modifications sont apportées. Si une CA subordonnée n’est pas rendue publique ou auditée, elle doit être limitée par le domaine.

  3. Les participants au programme doivent informer Microsoft par courrier électronique au moins 120 jours avant de transférer la propriété de la base de données racine ou subordonnée qui s’chaîne à une racine inscrit à une autre entité ou personne.

  4. Le code de raison doit être inclus dans les révocation de certificats intermédiaires. Les cacas doivent mettre à jour le CCADB lors de la révocation de certificats intermédiaires dans un délai de 30 jours.

  5. Les participants au programme conviennent que Microsoft peut contacter des clients que Microsoft estime être considérablement impactés par la suppression en attente d’une caas racine du programme.

Autres conditions requises

  1. Les caas commerciaux peuvent ne pas inscrire une autorité de contrôle d’accès racine dans le programme qui est destiné à être principalement approuvé en interne au sein d’une organisation (c’est-à-dire, Enterprise CAs).

  2. Si une entreprise utilise un sous-traitant pour agir sur tous les aspects 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 racine de confiance, Microsoft en informe l’autorité de certification responsable et demande à ce qu’elle révoque le certificat. L’ca doit révoquer le certificat ou demander une exception de Microsoft dans un délai de 24 heures après avoir reçu la notification de Microsoft. Microsoft examine les documents envoyés et informe l’ac de sa décision finale d’octroyer ou de refuser l’exception à sa seule discrétion. Si Microsoft n’accorde pas l’exception, l’ca doit révoquer le certificat dans les 24 heures après le refus de l’exception.


3. Exigences techniques du programme

Tous les CA du programme doivent respecter les exigences techniques du programme. Si Microsoft détermine qu’une cae n’est pas conforme aux exigences ci-dessous, Microsoft exclut cette cae du programme.

A. Exigences racines

  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 appropriée au marché de l’ac et lisible par un client ordinaire de ce marché.
    3. Extension Contraintes de base : doit être cA=true.
    4. L’extension de l’utilisation de clé DOIT être présente et doit être marquée comme critique. Les positions des bits pour KeyCertSign et cRLSign DOIVENT être définies. Si la clé privée d’ca racine est utilisée pour signer des réponses OCSP, la bit de signature numérique DOIT être définie.
      • Les tailles de clé racine doivent répondre aux exigences détaillées dans la « Clé requise ».
  2. Les certificats à ajouter au magasin racine de confiance doivent être des certificats racines auto-signés.
  3. Les nouveaux CA racines doivent être valides pendant 8 ans au minimum et jusqu’à 25 ans à partir de la date de soumission.
  4. Les CA racines participants peuvent ne pas émettre de nouveaux certificats RSA 1024 bits pour les racines couvertes par ces exigences.
  5. Tous les certificats d’entité de fin doivent contenir une extension AIA avec une URL OCSP valide. Ces certificats peuvent également contenir une extension CDP contenant une URL CRL valide. Tous les autres types de certificats doivent contenir soit une extension AIA avec une URL OCSP, soit une extension CDP avec une URL CRL valide
  6. Les clés privées et les noms des sujets doivent être uniques par certificat racine. réutilisation des clés privées ou des noms d’objet dans les certificats racines suivants par la même certification peut entraîner des problèmes inattendus de chaîne de certificats. Les serveurs de noms doivent générer une nouvelle clé et appliquer un nouveau nom de sujet lors de la génération d’un nouveau certificat racine avant la distribution par Microsoft.
  7. Les CA du secteur public doivent restreindre l’authentification des serveurs aux domaines de niveau supérieur émis par le gouvernement et peuvent uniquement émettre d’autres certificats aux codes de pays ISO3166 dont le pays a le contrôle souverain ( https://aka.ms/auditreqs voir la section III pour la définition d’une « administration publique »). Ces DD TLD émis par le gouvernement sont référez-vous dans les contrats respectifs de chaque organisme d’administration responsable.
  8. L’émission de certificats d’certification qui s’approvisionnement en chaîne à une caas racine participant doit séparer les utilisations de l’authentification serveur, du S/MIME, de la signature du code et de l’horodaage. Cela signifie qu’une seule authentification d’émission ne doit pas combiner l’authentification du serveur avec S/MIME, la signature de code ou l’horodament d’une référence EKU. Un intermédiaire distinct doit être utilisé pour chaque cas d’utilisation.
  9. Les certificats d’entité de fin doivent respecter les exigences relatives au type d’algorithme et à la taille de clé des certificats d’abonné répertoriés à l’annexe A du forum du cab - Conditions de référence, à l’emplacement https://cabforum.org/baseline-requirements-documents/.
  10. Les responsables des stratégies de certification doivent déclarer l’une des stratégies OID suivantes dans son certificat d’entité final 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. Ev Code Signing 2.23.140.1.3
    6. Signature de code non-EV 2.23.140.1.4.1
  11. Les certificats d’entité de fin qui incluent une extension Contraintes de base conformément à IETF RFC 5280 doivent avoir le champ cA sur FALSE et le champ pathLenConstraint doit être absent.
  12. Une caas doit limiter techniquement un répondant OCSP de telle façon que la seule référence EKU autorisée est la signature OCSP.
  13. Une cae doit pouvoir révoquer un certificat à une date spécifique, comme demandé par Microsoft.

B. Exigences relatives aux signatures

Algorithme Toutes les utilisations, à l’exception de la signature du code et de l’horodament Utilisation de la signature et de l’horodaage de code
Algorithmes de digeste SHA2 (SHA256, SHA384, SHA512) SHA2 (SHA256, SHA384, SHA512)
RSA 2048 4096 (Nouvelle racine uniquement)
ECC /ECDSA NIST P-256, P-384, P-521 NIST P-256, P-384, P-521

C. Conditions requises pour la révocation

  1. L’ca doit avoir une stratégie de révocation documentée et doit avoir la possibilité de révoquer tout certificat qui lui est dû.
  2. Les CA qui émettrent des certificats d’authentification du serveur doivent prendre en charge les conditions suivantes pour les intervenants OCSP :
    1. Validité minimale de huit (8) heures ; Validité maximale de sept (7) jours ; et
    2. La prochaine mise à jour doit être disponible au moins huit (8) heures avant l’expiration de la période en cours. Si la validité est plus de 16 heures, la prochaine mise à jour doit être disponible au 02/01/2 de la période de validité.
  3. Tous les certificats émis par une base de données racine doivent prendre en charge l’extension de point de distribution CRL et/ou AIA contenant une URL de répondant OCSP.
  4. L’ca ne doit pas utiliser le certificat racine pour émettre des certificats d’entité finale.
  5. Si une autorité de certification d’autorité de certification problèmes les certificats de signature de code, elle doit utiliser une autorité de horodaté qui est conforme au RFC 3161, « Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP) ».

D. Conditions requises pour le certificat racine de signature de code

  1. Les certificats racines qui prennent en charge l’utilisation de la signature de code peuvent être supprimés de la distribution par le programme 10 ans à compter de la date de distribution d’un certificat racine de remplacement, ou plus tôt, si cela est demandé par l’ac.
  2. Les certificats racines qui restent en distribution afin de prendre en charge uniquement l’utilisation de la signature de code au-delà de leur durée de vie de sécurité des algorithmes (par exemple, RSA 1024 = 2014, RSA 2048 = 2030) peuvent être définies sur « désactiver » dans le système d’exploitation Windows 10.

E. Conditions requises pour la référence EKU

  1. Les EK doivent fournir une justification d’entreprise pour toutes les EKUs attribuées à leur certificat racine. La justification peut être sous la forme de preuves publiques d’une entreprise en cours d’émission de certificats d’un ou de plusieurs types, ou d’un plan commercial montrant l’intention d’émettre ces certificats à court terme (dans un délai d’un an à la fin de la distribution du certificat racine par le programme).

  2. Microsoft activera uniquement les EKUs suivants :

    1. Authentification du serveur =1.3.6.1.5.5.7.3.1
    2. Authentification client =1.3.6.1.5.5.7.3.2
    3. Secure E-mail EKU=1.3.6.1.5.5.7.3.4
    4. Horodament EKU=1.3.6.1.5.5.7.3.8
    5. Document Signing EKU=1.3.6.1.4.1.311.10.3.12
    • Cette référence EKU est utilisée pour signer des documents dans Office. Elle n’est pas requise pour les autres utilisations de la signature de document.

F. Windows 10 signature de code du mode kernel (KMCS)

Windows 10 niveaux élevés pour valider les pilotes du mode noyau. Les pilotes doivent être signés par Microsoft et un partenaire du programme en utilisant les exigences de validation étendue. Tous les développeurs qui souhaitent inclure leurs pilotes en mode noyau dans Windows doivent suivre les procédures décrites par l’équipe de développement de matériel Microsoft. La documentation relative au programme est à trouver ici