Delen via

Programmavereisten - Vertrouwd basisprogramma van Microsoft

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 onbeperkte ondergeschikte 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 Principes en Criteria voor 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 verstrekte contactpersonen of aliassen moet een dag en nacht beschikbaar communicatiekanaal zijn voor verzoek om intrekking of andere incidentbeheer situaties.

  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 van tevoren per e-mail informeren voordat het eigendom wordt overgedragen van een geregistreerde oorspronkelijke of sub-CA die ketent naar een geregistreerde oorspronkelijke CA 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 zij mogelijk aanzienlijk worden beïnvloed door de voorgenomen verwijdering van een hoofdcertificaat 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 attribuut CN moet in een taal zijn die geschikt is voor de markt van de CA en leesbaar is voor een doorsnee klant in die markt.
    3. Uitbreiding basisbeperkingen: moet cA=true zijn.
    4. De extensie KeyUsage moet verplicht aanwezig zijn en als kritiek worden gemarkeerd. 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 de betrouwbare root store, moeten zelfondertekende root-certificaten 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 mogen geen nieuwe 1024-bits RSA-certificaten uitgeven van roots 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 afzonderlijke tussenliggende 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 de Certificate Policy-extensie van het eindentiteitscertificaat.
    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 gevalideerde legacy 2.23.140.1.5.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 Meervoudig 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 Gevalideerde meervoudig doel 2.23.140.1.5.3.2.
    14. S/MIME-sponsor gevalideerd Strict 2.23.140.1.5.3.3.
    15. S/MIME Individueel gevalideerd 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. Eind-entiteitscertificaten met een Basic Constraints-extensie in overeenstemming met IETF RFC 5280 moeten het cA-veld ingesteld hebben op FALSE en het veld pathLenConstraint moet afwezig zijn.
  14. Een CA moet een OCSP-responder zodanig technisch beperken dat OCSP-ondertekening de enige toegestane EKU 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 Code-ondertekening en tijdstempeling gebruik
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 elk certificaat dat het uitgeeft 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 bij de volgende publicatietijd van de 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 eindgebruikercertificaten 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-ondertekeningsaudits 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 de codeondertekening in kernelmodus van Windows 10

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.

  • Last updated on