Delen via

Programmavereisten - Vertrouwd basisprogramma van Microsoft

  • Artikel

1. Inleiding

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

Notitie

2. Doorlopende programmavereisten

Auditvereisten

  1. Deelnemers aan het programma moeten Microsoft bewijs verstrekken van een in aanmerking komende audit (zie https://aka.ms/auditreqs) voor elke basis-, niet-getrainde onderliggende CA en kruisondertekend certificaat, voordat commerciële activiteiten worden uitgevoerd en daarna op jaarbasis.
  2. Deelnemers aan het programma moeten de verantwoordelijkheid nemen om ervoor te zorgen dat alle niet-getrainde onderliggende CA's en kruisondertekende certificaten voldoen aan de programmacontrolevereisten.
  3. CA's moeten alle auditrapporten openbaar maken voor niet-getrainde onderliggende CA's.
  4. CA-providers moeten ervoor zorgen dat hun S/MIME-basis-CA's en alle onderliggende CA's die S/MIME-certificaten kunnen verlenen, zijn gecontroleerd op basis van de meest recente versie van ten minste een van de onderstaande sets criteria. Deze controle moet minstens één keer per jaar plaatsvinden. Een eerste controleperiode mag niet later beginnen dan 1 september 2023.
    • WebTrust Principles and Criteria for Certification Authorities – S/MIME
    • ETSI EN 119 411-6 LCP, NCP of NCP+

Communicatie- en openbaarmakingsvereisten

  1. Deelnemers aan het programma moeten Microsoft de identiteiten van ten minste twee vertrouwde agents verstrekken om als vertegenwoordiger van het programma en één algemene e-mailalias te fungeren. Deelnemers aan het programma moeten Microsoft informeren over het verwijderen of toevoegen van personeel als een vertrouwde agent. Deelnemers aan het programma gaan akkoord met het ontvangen van kennisgevingen via e-mail en moeten Microsoft een e-mailadres verstrekken 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 opgegeven contactpersonen of aliassen moet een communicatiekanaal van 24/7 zijn voor intrekkingsaanvragen of andere situaties van incidentbeheer.

  2. De deelnemer aan het programma moet de volledige PKI-hiërarchie (niet-gescheiden onderliggende CA, kruisondertekende niet-ingeschreven basis-CA's, onderliggende CA's, EKU's, certificaatbeperkingen) op jaarbasis aan Microsoft vrijgeven, inclusief certificaten die zijn uitgegeven aan CA's 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 een domeinbeperking hebben.

  3. Deelnemers aan het programma moeten Microsoft ten minste 120 dagen per e-mail informeren voordat het eigendom wordt overgedragen van geregistreerde basis- of onderliggende CA die is gekoppeld aan een geregistreerde hoofdmap aan een andere entiteit of persoon.

  4. Redencode moet worden opgenomen in intrekkingen voor tussenliggende certificaten. CA's moeten de CCADB bijwerken bij het intrekken van tussenliggende certificaten binnen 30 dagen.

  5. Deelnemers aan het programma gaan ermee akkoord dat Microsoft contact kan opnemen met klanten waarvan Microsoft denkt dat dit aanzienlijk wordt beïnvloed door het in behandeling verwijderen van een basis-CA uit het programma.

Andere vereisten

  1. Commerciële CA's registreren mogelijk geen basis-CA in het programma dat voornamelijk intern moet worden vertrouwd binnen een organisatie (d.w.w.v. Ondernemings-CA's).

  2. Als een CA een onderaannemer gebruikt om een aspect van zijn bedrijf te exploiteren, neemt de CA de verantwoordelijkheid voor de bedrijfsvoering van de onderaannemer.

  3. Als Microsoft, naar eigen goeddunken, een certificaat identificeert waarvan het gebruik of de kenmerken in strijd zijn met de doelstellingen van het vertrouwde basisprogramma, zal Microsoft de verantwoordelijke CERTIFICERINGsinstantie informeren en aanvragen dat het certificaat wordt ingetrokken. De CA moet het certificaat intrekken of binnen 24 uur na ontvangst van de kennisgeving van Microsoft een uitzondering aanvragen. Microsoft beoordeelt ingediend materiaal en informeert de CA over zijn definitieve beslissing om de uitzondering naar eigen goeddunken te verlenen of te weigeren. In het geval dat Microsoft de uitzondering niet verleent, moet de CA het certificaat binnen 24 uur intrekken nadat de uitzondering is geweigerd.

3. Technische vereisten voor programma's

Alle CA's in het programma moeten voldoen aan de technische vereisten van het programma. Als Microsoft bepaalt dat een CA niet voldoet aan de onderstaande vereisten, sluit Microsoft die CA uit van het programma.

A. Hoofdvereisten

  1. Basiscertificaten moeten x.509 v3-certificaten zijn.
    1. Het CN-kenmerk moet de uitgever identificeren en moet uniek zijn.
    2. Het KENMERK CN moet zich in een taal hebben die geschikt is voor de markt van de CA en leesbaar is door een typische klant in die markt.
    3. Uitbreiding basisbeperkingen: moet cA=true zijn.
    4. De extensie Sleutelgebruik moet aanwezig zijn en moet worden gemarkeerd als kritiek. Bitposities voor KeyCertSign en cRLSign moeten worden ingesteld. Als de persoonlijke sleutel van de basis-CA wordt gebruikt voor het ondertekenen van OCSP-antwoorden, moet de digitalSignature-bit worden ingesteld.
      • Basissleutelgrootten moeten voldoen aan de vereisten die hieronder worden beschreven in 'Handtekeningvereisten'.
  2. Certificaten die moeten worden toegevoegd aan het vertrouwde basisarchief moeten zelfondertekende basiscertificaten zijn.
  3. Nieuw geslagen basis-CA's moeten minimaal acht jaar geldig zijn en maximaal 25 jaar vanaf de datum van indiening.
  4. Deelnemende basis-CA's geven mogelijk geen nieuwe 1024-bits RSA-certificaten uit die onder deze vereisten vallen.
  5. Alle verlenende CA-certificaten moeten een CDP-extensie bevatten met een geldige CRL en/of een AIA-extensie voor een OCSP-responder. Een end-entitycertificaat kan een AIA-extensie bevatten met een geldige OCSP-URL en/of een CDP-extensie die verwijst naar een geldig HTTP-eindpunt met de CRL. Als een AIA-extensie met een geldige OCSP-URL NIET is opgenomen, moet het resulterende CRL-bestand 10 MB zijn <.
  6. Persoonlijke sleutels en onderwerpnamen moeten uniek zijn per basiscertificaat; hergebruik van persoonlijke sleutels of onderwerpnamen in volgende basiscertificaten door dezelfde CA kan leiden tot onverwachte problemen met het koppelen van certificaten. CA's moeten een nieuwe sleutel genereren en een nieuwe onderwerpnaam toepassen bij het genereren van een nieuw basiscertificaat vóór de distributie door Microsoft.
  7. Ca's van de overheid moeten serververificatie beperken tot door de overheid uitgegeven domeinen op het hoogste niveau en mogen alleen andere certificaten uitgeven aan de ISO3166 landcodes waarover het land onafhankelijke controle heeft (zie https://aka.ms/auditreqs sectie III voor de definitie van een overheids-CA). Deze door de overheid uitgegeven TLD's worden genoemd in het respectieve contract van elke CA.
  8. Het verlenen van CA-certificaten die zijn gekoppeld aan een deelnemende basis-CA, moet serververificatie, S/MIME, ondertekening van code en tijdstempels scheiden. Dit betekent dat één verlenende CA geen serververificatie mag combineren met S/MIME, ondertekening van code of tijdstempels voor EKU. Voor elke use-case moet een afzonderlijk tussenliggend tussenliggend exemplaar worden gebruikt.
  9. Certificaten voor eindentiteiten moeten voldoen aan de vereisten voor algoritmetype en sleutelgrootte voor abonneecertificaten die worden vermeld in bijlage A van de basislijnvereisten van het CAB-forum in https://cabforum.org/baseline-requirements-documents/.
  10. CA's moeten een van de volgende beleids-OID's declareren in het certificaatbeleidsuitbreidingscertificaat voor eindentiteit.
    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. Niet-EV-codeondertekening 2.23.140.1.4.1.
    6. S/MIME-postvak gevalideerd verouderde 2.23.140.1.5.1.1.1.
    7. S/MIME-postvak gevalideerd multipurpose 2.23.140.1.5.1.2.
    8. S/MIME-postvak gevalideerd strikt 2.23.140.1.5.1.3.
    9. S/MIME-organisatie gevalideerd verouderde 2.23.140.1.5.2.1.
    10. S/MIME-organisatie gevalideerd multipurpose 2.23.140.1.5.2.2.
    11. S/MIME-organisatie gevalideerd strikt 2.23.140.1.5.2.3.
    12. S/MIME-sponsor gevalideerd legacy 2.23.140.1.5.3.1.
    13. S/MIME Sponsor Gevalideerd multipurpose 2.23.140.1.5.3.2.
    14. S/MIME-sponsor gevalideerd strict 2.23.140.1.5.3.3.
    15. S/MIME Individual Validated Legacy 2.23.140.1.5.4.1.
    16. S/MIME Individual Validated Multipurpose 2.23.140.1.5.4.2.
    17. S/MIME Individueel gevalideerd strikt 2.23.140.1.5.4.3.
  11. Vanaf augustus 2024 worden alle aangepaste EV SSL-OID's die worden beheerd door het Vertrouwde basisprogramma en onze respectieve hulpprogramma's verwijderd en vervangen door CA/B Forum conform EV SSL OID (2.23.140.1.1). Het Microsoft Edge-team implementeert controles voor EV SSL OID (2.23.140.1.1) in de browser, zodat andere EV SSL-OID's niet meer worden geaccepteerd om te worden afgestemd op Edge en om compatibiliteitsproblemen te voorkomen.
  12. CA's hebben mogelijk niet meer dan 2 OID's toegepast op hun basiscertificaat.
  13. Eindentiteitscertificaten met een uitbreiding basisbeperkingen in overeenstemming met IETF RFC 5280 moeten het cA-veld hebben ingesteld op FALSE en het veld pathLenConstraint moet afwezig zijn.
  14. Een CA moet technisch een OCSP-responder beperken, zodat de enige toegestane EKU OCSP-ondertekening is.
  15. Een CA moet een certificaat kunnen intrekken op een specifieke datum, zoals aangevraagd door Microsoft.

B. Handtekeningvereisten

Algoritme Alle toepassingen, met uitzondering van ondertekening van programmacode en tijdstempels Gebruik van ondertekenings- en tijdstempels voor code
Samenvattingsalgoritmen SHA2 (SHA256, SHA384, SHA512) SHA2 (SHA256, SHA384, SHA512)
RSA 2048 4096 (alleen nieuwe roots)
ECC /ECDSA NIST P-256, P-384, P-521 Niet ondersteund

Opmerking:

  • Handtekeningen die gebruikmaken van elliptische curvecryptografie (ECC), zoals ECDSA, worden niet ondersteund in Windows- en nieuwere Windows-beveiligingsfuncties. Gebruikers die deze algoritmen en certificaten gebruiken, ondervinden verschillende fouten en mogelijke beveiligingsrisico's. Het vertrouwde basisprogramma van Microsoft raadt aan dat ECC/ECDSA-certificaten niet aan abonnees mogen worden uitgegeven vanwege deze bekende incompatibiliteit en risico.
  • Ondertekening van code biedt geen ondersteuning voor ECC of sleutels > 4096

C. Intrekkingsvereisten

  1. CA's moeten beschikken over een gedocumenteerd intrekkingsbeleid en moeten over de mogelijkheid beschikken om certificaatproblemen in te trekken.

  2. OCSP-respondervereisten: a. Minimale geldigheid van acht (8) uur; Maximale geldigheid van zeven (7) dagen; en b. De volgende update moet ten minste acht (8) uur beschikbaar zijn voordat de huidige periode verloopt. Als de geldigheid langer is dan 16 uur, moet de volgende update beschikbaar zijn om 1/2 de geldigheidsperiode.

  3. CRL-aanbevelingen wanneer OCSP niet aanwezig is: a. Moet microsoft-specifieke extensie 1.3.6.1.4.1.311.21.4 bevatten (volgende CRL publiceren). b. Nieuwe CRL moet beschikbaar zijn op de publicatietijd van de volgende CRL. c. De maximale grootte van het CRL-bestand (volledige CRL of gepartitioneerde CRL) mag niet groter zijn dan 10 miljoen.

    Notitie

    Het doel van sectie 3.C.3- CRL-aanbevelingen wanneer OCSP niet aanwezig is, is om eindgebruikers dekking te bieden in gevallen van massaintrekking.

  4. De CA mag het basiscertificaat niet gebruiken om certificaten voor eindentiteit uit te geven.

  5. Als een CA certificaten voor ondertekening van programmacode uitgeeft, 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 basiscertificaat voor ondertekening van code

  1. Basiscertificaten die ondersteuning bieden voor het gebruik van codeondertekening, kunnen 10 jaar na de distributiedatum van een vervangend rollover-basiscertificaat of eerder worden verwijderd uit distributie door het programma, indien aangevraagd door de CA.
  2. Basiscertificaten die in distributie blijven ter ondersteuning van alleen het gebruik van codeondertekening na hun levensduur van de algoritmebeveiliging (bijvoorbeeld RSA 1024 = 2014, RSA 2048 = 2030) kunnen worden ingesteld op 'uitschakelen' in het Windows 10-besturingssysteem.
  3. Vanaf februari 2024 accepteert Of herkent Microsoft geen EV Code-ondertekeningscertificaten meer en accepteert CCADB geen EV Code-ondertekeningscontroles meer. Vanaf augustus 2024 worden alle EV Code-ondertekenings-OID's verwijderd uit bestaande basismappen in het vertrouwde basisprogramma van Microsoft en worden alle certificaten voor ondertekening van programmacode gelijk behandeld.

E. EKU-vereisten

  1. CA's moeten een zakelijke reden opgeven voor alle EKU's die zijn toegewezen aan hun basiscertificaat. De rechtvaardiging kan bestaan in de vorm van openbaar bewijs van het verlenen van certificaten van een type of type, of van een bedrijfsplan dat aangeeft dat deze certificaten op korte termijn moeten worden uitgegeven (binnen één jaar na distributie van basiscertificaten door het programma).

  2. Microsoft schakelt alleen de volgende EKU's in:

    1. Serververificatie =1.3.6.1.5.5.7.3.1
    2. Clientverificatie =1.3.6.1.5.5.7.3.2
    3. Beveiligde e-mail-EKU=1.3.6.1.5.5.7.3.4
    4. Tijdstempel EKU=1.3.6.1.5.5.7.3.8
    5. EKU voor documentondertekening=1.3.6.1.4.1.311.10.3.12
    • Deze EKU wordt gebruikt voor het ondertekenen van documenten in Office. Dit is niet vereist voor andere toepassingen voor documentondertekening.

F. Vereisten voor ondertekening van codeondertekening (KMCS) voor Windows 10-kernelmodus

Windows 10 heeft verhoogde vereisten voor het valideren van kernelmodusstuurprogramma's. Stuurprogramma's moeten zijn ondertekend door Zowel Microsoft als een Programma-partner met behulp van uitgebreide validatievereisten. Alle ontwikkelaars die hun kernelmodusstuurprogramma's in Windows willen opnemen, moeten de procedures volgen die worden beschreven door het Microsoft Hardware Development Team. Zie het Partnercentrum voor Windows-hardware voor meer informatie.