Programmavereisten - Microsoft Trusted Root Program

1. Inleiding

Het Microsoft Root Certificate Program ondersteunt de distributie van hoofdcertificaten, zodat klanten hun producten Windows vertrouwen. Op deze pagina worden de algemene en technische vereisten van het programma beschreven.

Opmerking

2. Doorlopende programmavereisten

Auditvereisten

  1. Deelnemers aan programma's moeten microsoft bewijzen van een gekwalificeerde audit (zie https://aka.ms/auditreqs) voor elke onderliggende hoofd- en niet-geconstrainde ca, en een kruisgesigneerd certificaat, voordat ze commerciële bewerkingen uitvoeren en daarna op jaarbasis.
  2. Deelnemers aan programma's moeten de verantwoordelijkheid nemen om ervoor te zorgen dat alle niet-geconstrainde ondergeschikte CAs en cross-signed certificaten voldoen aan de programmaauditvereisten.
  3. CAs moeten alle auditrapporten openbaar maken voor niet-geconstrainde ondergeschikte CAs.

Communicatie- en openbaarmakingsvereisten

  1. Deelnemers aan het programma moeten Microsoft de identiteiten geven van ten minste twee 'Vertrouwde agenten' om als vertegenwoordigers voor het programma en één algemene e-mailalias te fungeren. Deelnemers aan het programma moeten Microsoft op de hoogte stellen bij het verwijderen of op de hoogte stellen van personeel als vertrouwde agent. Deelnemers aan het programma stemmen ermee in om per e-mail kennisgevingen te ontvangen en moeten Microsoft een e-mailadres geven om officiële kennisgevingen te ontvangen. Deelnemers aan het programma moeten ermee akkoord gaan dat de kennisgeving van kracht is wanneer Microsoft een e-mail of officiële brief verzendt. Ten minste één van de verstrekte contactpersonen of aliassen moet een 24/7 bewaakt communicatiekanaal zijn voor intrekkingsaanvragen of andere situaties van incidentbeheer.

  2. De deelnemer aan het programma moet de volledige PKI-hiërarchie (niet-beperkte onderliggende CA, cross-signed niet-ingeschreven hoofd-CAs, ondergeschikte CAs, EKUs, certificaatbeperkingen) jaarlijks aan Microsoft bekendmaken, inclusief certificaten die zijn uitgegeven aan CAs die worden beheerd door externe derden binnen de CCADB. Deelnemers aan het programma moeten deze informatie nauwkeurig houden in de CCADB wanneer er wijzigingen optreden. Als een onderliggende ca. niet openbaar wordt gemaakt of gecontroleerd, moet deze zijn beperkt tot het domein.

  3. Deelnemers aan het programma moeten Microsoft ten minste 120 dagen per e-mail informeren voordat ze het eigendom van de geregistreerde hoofd- of onderliggende ca.v.t. overdragen die ketens heeft naar een ingeschreven hoofdmap naar een andere entiteit of persoon.

  4. Redencode moet worden opgenomen in intrekkingen voor tussentijdse certificaten. CAs moeten de CCADB bijwerken wanneer u tussentijdse certificaten binnen 30 dagen inroept.

  5. Deelnemers aan programma's gaan ermee akkoord dat Microsoft contact kan opnemen met klanten die volgens Microsoft mogelijk aanzienlijk worden beïnvloed door het in behandeling zijnde verwijderen van een hoofd-ca. uit het programma.

Andere vereisten

  1. Commerciële CAs kunnen geen hoofdinstantie registreren voor het programma dat bedoeld is om voornamelijk intern te worden vertrouwd binnen een organisatie (dat wil zeggen enterprise-ca's).

  2. Als een ca. een onderaannemer gebruikt om een aspect van zijn bedrijf uit te voeren, neemt de ca. de verantwoordelijkheid voor de bedrijfsactiviteiten van de onderaannemer op zich.

  3. Als Microsoft naar eigen goed inzicht een certificaat identificeert waarvan het gebruik of de kenmerken strijdig zijn met de doelstellingen van het vertrouwde hoofdprogramma, zal Microsoft de verantwoordelijke certificeringsinstantie op de hoogte stellen en verzoeken het certificaat in te trekken. De certificeringsaanvraag moet het certificaat intrekken of een uitzondering aanvragen bij Microsoft binnen 24 uur na ontvangst van de kennisgeving van Microsoft. Microsoft zal het ingediende materiaal beoordelen en de ca. op de hoogte stellen van de uiteindelijke beslissing om de uitzondering naar eigen goed inzicht toe te geven of te weigeren. Als Microsoft de uitzondering niet verleent, moet de ca. het certificaat binnen 24 uur na de geweigerde uitzondering intrekken.


3. Technische programmavereisten

Alle CAs in het programma moeten voldoen aan de technische programmavereisten. Als Microsoft vaststelt dat een ca. niet voldoet aan de onderstaande vereisten, sluit Microsoft deze ca uit van het programma.

A. Hoofdvereisten

  1. Hoofdcertificaten moeten x,509 v3-certificaten zijn.
    1. Het CN-kenmerk moet de uitgever identificeren en moet uniek zijn.
    2. Het CN-kenmerk moet zich in een taal hebben die geschikt is voor de markt van de CA en kan worden gelezen door een gewone klant in die markt.
    3. Extensie Basisbeperkingen: moet cA=true zijn.
    4. Key Usage extension MUST be present and MUST be marked critical. Bitposities voor KeyCertSign en cRLSign MOETEN worden ingesteld. Als de hoofd-CA Private Key wordt gebruikt voor het ondertekenen van OCSP-antwoorden, moet de digitalSignature-bit MUST worden ingesteld.
      • Hoofdsleutelgrootten moeten voldoen aan de vereisten die worden beschreven in 'Belangrijke vereisten'.
  2. Certificaten die moeten worden toegevoegd aan het vertrouwde hoofdopslag moeten zelf ondertekende hoofdcertificaten zijn.
  3. Nieuw toegevoegde hoofd-AA's moeten geldig zijn voor minimaal 8 jaar en maximaal 25 jaar vanaf de datum van indiening.
  4. Deelnemende hoofd-AA's geven mogelijk geen nieuwe 1024-bits RSA-certificaten af op basis van wortels die onder deze vereisten vallen.
  5. Alle end-entity certificaten moeten een AIA-extensie met een geldige OCSP-URL bevatten. Deze certificaten kunnen ook een CDP-extensie bevatten die een geldige CRL-URL bevat. Alle andere certificaattypen moeten een AIA-extensie bevatten met een OCSP-URL of een CDP-extensie met een geldige CRL-URL
  6. Persoonlijke sleutels en onderwerpnamen moeten uniek zijn per hoofdcertificaat. hergebruik van privésleutels of onderwerpnamen in de volgende hoofdcertificaten door dezelfde ca kan leiden tot onverwachte problemen met het ketenen van certificaten. CA's moeten een nieuwe sleutel genereren en een nieuwe onderwerpnaam toepassen bij het genereren van een nieuw hoofdcertificaat vóór de distributie door Microsoft.
  7. Overheidsauthenticatie moet serververificatie beperken tot door de overheid uitgegeven domeinen op het hoogste niveau en mogen alleen andere certificaten uitgeven aan de ISO3166-landcodes waar het land soevereine controle over heeft ( https://aka.ms/auditreqs zie sectie III voor de definitie van een 'Government CA'). Deze door de overheid uitgegeven TLD's worden genoemd in het desbetreffende contract van elke ca.
  8. Als u CA-certificaten uitvaardigt die zijn geketend aan een deelnemende hoofdinstantie, moeten Serververificatie, S/MIME, Code Signing en Tijdstempeling worden gescheiden. Dit betekent dat één uitgifte-instantie serververificatie niet mag combineren met S/MIME, code signing of time stamping EKU. Voor elke gebruikscase moet een aparte tussenliggende tussenliggende toepassing worden gebruikt.
  9. Eindentiteitscertificaten moeten voldoen aan de vereisten voor het algoritmetype en de sleutelgrootte voor abonneecertificaten die worden vermeld in bijlage A van de basislijnvereisten van het CAB-forum https://cabforum.org/baseline-requirements-documents/op .
  10. CAs moeten een van de volgende beleids-OID's declareerden in het certificaat van de eindentiteit van de certificaatuitbreidingsextensie certificaat voor certificaatbeleid:
    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. Niet-EV-code ondertekenen 2.23.140.1.4.1
  11. Certificaten van eindentiteiten die een extensie Basisbeperkingen bevatten in overeenstemming met IETF RFC 5280, moeten het cA-veld hebben ingesteld op ONWAAR en het veld pathLenConstraint moet afwezig zijn.
  12. Een CA moet een OCSP-responder technisch beperken, zodat ocsp-ondertekening de enige EKU is die is toegestaan.
  13. Een ca. moet een certificaat kunnen intrekken op een specifieke datum, zoals door Microsoft is gevraagd.

B. Handtekeningvereisten

Algoritme Alle toepassingen behalve voor code ondertekenen en tijdstempeling Code Signing and Time Stamping Use
Digest-algoritmen SHA2 (SHA256, SHA384, SHA512) SHA2 (SHA256, SHA384, SHA512)
RSA 2048 4096 (alleen nieuwe roots)
ECC /ECDSA NIST P-256, P-384, P-521 NIST P-256, P-384, P-521

C. Intrekkingsvereisten

  1. De ca. moet een gedocumenteerd intrekkingsbeleid hebben en moet de mogelijkheid hebben om eventuele certificaten die door de certificering worden afgegeven, in te trekken.
  2. CAs die serververificatiecertificaten uitgeven, moeten de volgende vereisten voor OCSP-antwoorden ondersteunen:
    1. Minimale geldigheid van acht (8) uur; Maximale geldigheid van zeven (7) dagen; en
    2. De volgende update moet ten minste acht (8) uur vóór de huidige periode beschikbaar zijn. Als de geldigheid langer is dan 16 uur, moet de volgende update beschikbaar zijn op 1/2 van de geldigheidsperiode.
  3. Alle certificaten die zijn uitgegeven vanuit een hoofd-ca moeten de uitbreiding van het CRL-distributiepunt en/of de AIA met een URL voor OCSP-antwoorden ondersteunen.
  4. De certificeringsinstelling mag het hoofdcertificaat niet gebruiken om certificaten voor eindentiteiten uit te geven.
  5. Als een certificeringsinstantie code ondertekeningscertificaten afkondigt, moet deze een Time Stamp Authority gebruiken die voldoet aan RFC 3161, 'Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP).'

D. Vereisten voor het ondertekenen van hoofdcertificaten voor code

  1. Hoofdcertificaten die ondersteuning bieden voor het ondertekenen van code, kunnen worden verwijderd uit de distributie door het programma 10 jaar na de distributiedatum van een vervangend hoofdcertificaat voor rollover of eerder, indien daarom wordt gevraagd door de CA.
  2. Hoofdcertificaten die nog steeds in distributie zijn om alleen het ondertekenen van code te ondersteunen na de levensduur van de algoritmebeveiliging (bijvoorbeeld RSA 1024 = 2014, RSA 2048 = 2030) kunnen zijn ingesteld op 'uitschakelen' in het Windows 10-besturingssysteem.

E. EKU-vereisten

  1. CAS's moeten een zakelijke rechtvaardiging bieden voor alle EKUs die aan hun hoofdcertificaat zijn toegewezen. De rechtvaardiging kan bestaan uit openbaar bewijs van een huidig bedrijf dat certificaten van een type of type uitdeelt, of een bedrijfsplan waarin wordt aangetoond dat het de bedoeling is deze certificaten op korte termijn af te geven (binnen één jaar na de distributie van hoofdcertificaten door het programma).

  2. Microsoft zal alleen de volgende EKUs inschakelen:

    1. Serververificatie =1.3.6.1.5.5.7.3.1
    2. Clientverificatie =1.3.6.1.5.5.7.3.2
    3. Secure E-mail EKU=1.3.6.1.5.5.7.3.4
    4. Tijdstempeling EKU=1.3.6.1.5.5.7.3.8
    5. Document Signing EKU=1.3.6.1.4.1.311.10.3.12
    • Deze EKU wordt gebruikt voor het ondertekenen van documenten binnen Office. Dit is niet vereist voor andere toepassingen voor het ondertekenen van documenten.

F. Windows 10 vereisten voor het ondertekenen van code voor de kernelmodus (KMCS)

Windows 10 heeft verhoogde vereisten voor het valideren van stuurprogramma's in de kernelmodus. Stuurprogramma's moeten worden ondertekend door zowel Microsoft als een programmapartner met uitgebreide validatievereisten. Alle ontwikkelaars die hun stuurprogramma's voor de kernelmodus willen laten Windows moeten de procedures volgen die zijn beschreven door het Microsoft Hardware Development Team. Programmadocumentatie vindt u hier