Dela via

Programkrav – Microsoft Trusted Root Program

  • Artikel

1. Inledning

Microsoft Root Certificate Program stöder distribution av rotcertifikat, vilket gör det möjligt för kunder att lita på Windows-produkter. På den här sidan beskrivs programmets allmänna och tekniska krav.

Kommentar

2. Krav för fortsatt program

Granskningskrav

  1. Programdeltagarna måste tillhandahålla Microsoft bevis för en kvalificerande granskning (se https://aka.ms/auditreqs) för varje rotcertifikatutfärdare, obehindrat underordnad certifikatutfärdare och korssignerat certifikat innan de genomför kommersiella åtgärder och därefter på årsbasis.
  2. Programdeltagarna måste ta ansvar för att se till att alla obehindrade underordnade certifikatutfärdare och korssignerade certifikat uppfyller programgranskningskraven.
  3. Certifikatutfärdare måste offentliggöra alla granskningsrapporter för obehindrade underordnade certifikatutfärdare.
  4. CA-leverantörer måste se till att deras S/MIME-aktiverade rotcertifikatutfärdare och alla underordnade certifikatutfärdare som kan utfärda S/MIME-certifikat har varit och kommer att fortsätta att granskas mot den senaste versionen av minst en av nedanstående uppsättningar kriterier. Den här granskningen måste ske minst en gång om året. En inledande granskningsperiod måste inledas senast den 1 september 2023.
    • WebTrust-principer och kriterier för certifikatutfärdare – S/MIME
    • ETSI EN 119 411-6 LCP, NCP eller NCP+

Krav för kommunikation och avslöjande

  1. Programdeltagare måste ange Microsofts identiteter för minst två "betrodda agenter" för att fungera som representanter för programmet och ett allmänt e-postalias. Programdeltagare måste informera Microsoft om borttagning eller tillägg av personal som betrodd agent. Programdeltagarna samtycker till att få meddelanden via e-post och måste ge Microsoft en e-postadress för att få officiella meddelanden. Programdeltagarna måste vara överens om att meddelandet gäller när Microsoft skickar ett e-postmeddelande eller ett officiellt brev. Minst en av de kontakter eller alias som tillhandahålls bör vara en 24/7 övervakad kommunikationskanal för begäranden om återkallande eller andra incidenthanteringssituationer.

  2. Programdeltagaren måste lämna ut sin fullständiga PKI-hierarki (icke-begränsad underordnad certifikatutfärdare, korssignerade icke-registrerade rotcertifikatutfärdare, underordnade certifikatutfärdare, EKU:er, certifikatbegränsningar) till Microsoft på årsbasis, inklusive certifikat som utfärdats till certifikatutfärdare som drivs av externa tredje parter inom CCADB. Programdeltagarna måste hålla den här informationen korrekt i CCADB när ändringar sker. Om en underordnad ca inte avslöjas eller granskas offentligt måste den vara domänbegränsad.

  3. Programdeltagare måste informera Microsoft via e-post minst 120 dagar innan ägarskapet för den registrerade roten eller den underordnade certifikatutfärdaren överförs som kedjar till en registrerad rot till en annan entitet eller person.

  4. Orsakskoden måste inkluderas i återkallningar för mellanliggande certifikat. Certifikatutfärdare måste uppdatera CCADB när de återkallar mellanliggande certifikat inom 30 dagar.

  5. Programdeltagarna är överens om att Microsoft kan kontakta kunder som Microsoft tror kan påverkas avsevärt av att en rotcertifikatutfärdare tas bort från programmet i väntan på borttagning.

Övriga krav

  1. Kommersiella certifikatutfärdare kanske inte registrerar en rotcertifikatutfärdare i programmet som främst är avsett att vara betrott internt inom en organisation (dvs. företagscertifikatutfärdare).

  2. Om en ca använder en underleverantör för att driva någon aspekt av sin verksamhet, kommer ca:en att ta ansvar för underleverantörens affärsverksamhet.

  3. Om Microsoft efter eget gottfinnande identifierar ett certifikat vars användning eller attribut bedöms strida mot målen för det betrodda rotprogrammet meddelar Microsoft den ansvariga certifikatutfärdare och begär att certifikatet återkallas. Certifikatutfärdare måste antingen återkalla certifikatet eller begära ett undantag från Microsoft inom 24 timmar efter att microsofts meddelande mottagits. Microsoft kommer att granska inskickade material och informera CA om sitt slutliga beslut att bevilja eller neka undantaget efter eget gottfinnande. Om Microsoft inte beviljar undantaget måste certifikatutfärdare återkalla certifikatet inom 24 timmar efter att undantaget nekats.

3. Tekniska krav för programmet

Alla certifikatutfärdare i programmet måste uppfylla de tekniska kraven för programmet. Om Microsoft bedömer att en ca inte uppfyller kraven nedan undantar Microsoft certifikatet från programmet.

A. Rotkrav

  1. Rotcertifikat måste vara x.509 v3-certifikat.
    1. CN-attributet måste identifiera utgivaren och måste vara unikt.
    2. CN-attributet måste vara på ett språk som är lämpligt för ca:ens marknad och läsbart av en typisk kund på den marknaden.
    3. Tillägg för grundläggande begränsningar: måste vara cA=true.
    4. Nyckelanvändningstillägget MÅSTE finnas och MÅSTE markeras som kritiskt. Bitpositioner för KeyCertSign och cRLSign MÅSTE anges. Om den privata rotcertifikatutfärdarnyckeln används för signering av OCSP-svar måste digitalSignature-biten anges.
      • Rotnyckelstorlekar måste uppfylla kraven som beskrivs i "Signaturkrav" nedan.
  2. Certifikat som ska läggas till i det betrodda rotarkivet måste vara självsignerade rotcertifikat.
  3. Nyligen minerade rotcertifikatutfärdare måste vara giltiga i minst åtta år, och högst 25 år, från och med den dag då de lämnades in.
  4. Deltagande rotcertifikatutfärdare kanske inte utfärdar nya 1024-bitars RSA-certifikat från rötter som omfattas av dessa krav.
  5. Alla utfärdande CA-certifikat måste innehålla antingen ett CDP-tillägg med en giltig CRL och/eller ett AIA-tillägg till en OCSP-svarare. Ett slutentitetscertifikat kan innehålla antingen ett AIA-tillägg med en giltig OCSP-URL och/eller ett CDP-tillägg som pekar på en giltig HTTP-slutpunkt som innehåller CRL. Om ett AIA-tillägg med en giltig OCSP-URL INTE ingår ska den resulterande CRL-filen vara <10 MB.
  6. Privata nycklar och ämnesnamn måste vara unika per rotcertifikat. återanvändning av privata nycklar eller ämnesnamn i efterföljande rotcertifikat av samma certifikatutfärdare kan leda till oväntade problem med certifikatlänkning. Certifikatutfärdare måste generera en ny nyckel och tillämpa ett nytt ämnesnamn när ett nytt rotcertifikat genereras före distributionen av Microsoft.
  7. Myndighetscertifikatutfärdare måste begränsa serverautentiseringen till myndighetsutfärdade toppnivådomäner och får endast utfärda andra certifikat till de ISO3166 landskoder som landet har suverän kontroll över (se https://aka.ms/auditreqs avsnitt III för definitionen av en "myndighetscertifikatutfärdare"). Dessa myndighetstilldelade TLD:er hänvisas till i varje ca:s respektive kontrakt.
  8. Utfärdande av CA-certifikat som länkas till en deltagande rotcertifikatutfärdare måste separera användning av serverautentisering, S/MIME, kodsignering och tidsstämpling. Det innebär att en enda utfärdande certifikatutfärdare inte får kombinera serverautentisering med S/MIME, kodsignering eller tidsstämpling av EKU. En separat mellanliggande måste användas för varje användningsfall.
  9. Slutentitetscertifikat måste uppfylla kraven för algoritmtyp och nyckelstorlek för prenumerantcertifikat som anges i bilaga A till CAB-forumets baslinjekrav som finns på https://cabforum.org/baseline-requirements-documents/.
  10. Certifikatutfärdare måste deklarera någon av följande princip-OID:er i certifikatets slutentitetscertifikat för certifikatprinciptillägget.
    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. Icke-EV-kodsignering 2.23.140.1.4.1.
    6. S/MIME-postlådan verifierade äldre 2.23.140.1.5.1.1.
    7. S/MIME Mailbox Validated Multipurpose 2.23.140.1.5.1.2.
    8. S/MIME-postlådan verifierade strikt 2.23.140.1.5.1.3.
    9. S/MIME-organisationen verifierade äldre 2.23.140.1.5.2.1.
    10. S/MIME Organization Validated Multipurpose 2.23.140.1.5.2.2.
    11. S/MIME-organisationen verifierade strikt 2.23.140.1.5.2.3.
    12. S/MIME Sponsor Validated Legacy 2.23.140.1.5.3.1.
    13. S/MIME Sponsor Validated Multipurpose 2.23.140.1.5.3.2.
    14. S/MIME-sponsor verifierad strikt 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 Individual Validated Strict 2.23.140.1.5.4.3.
  11. Från och med augusti 2024 tas alla anpassade EV SSL-OID:er som hanteras av det betrodda rotprogrammet och våra respektive verktyg bort och ersätts med CA/B Forum-kompatibel EV SSL OID (2.23.140.1.1). Microsoft Edge-teamet implementerar kontroller för EV SSL OID (2.23.140.1.1) i webbläsaren, så andra EV SSL-OID:er accepteras inte längre för att anpassa sig till Edge och för att undvika inkompatibiliteter.
  12. Certifikatutfärdare får inte ha fler än 2 OID:er som tillämpas på deras rotcertifikat.
  13. Slutentitetscertifikat som innehåller ett basic constraints-tillägg i enlighet med IETF RFC 5280 måste ha cA-fältet inställt på FALSE och fältet pathLenConstraint måste vara frånvarande.
  14. En certifikatutfärdare måste tekniskt sett begränsa en OCSP-svarare så att den enda EKU som tillåts är OCSP-signering.
  15. En certifikatutfärdare måste kunna återkalla ett certifikat till ett visst datum enligt Microsofts begäran.

B. Signaturkrav

Algoritm Alla användningsområden förutom kodsignering och tidsstämpling Användning av kodsignering och tidsstämpling
Sammanfattade algoritmer SHA2 (SHA256, SHA384, SHA512) SHA2 (SHA256, SHA384, SHA512)
RSA 2048 4096 (endast nya rötter)
ECC/ECDSA NIST P-256, P-384, P-521 Stöds inte

Obs!

  • Signaturer med hjälp av elliptisk kurvkryptografi (ECC), till exempel ECDSA, stöds inte i Windows och nyare Säkerhetsfunktioner i Windows. Användare som använder dessa algoritmer och certifikat kommer att drabbas av olika fel och potentiella säkerhetsrisker. Microsofts betrodda rotprogram rekommenderar att ECC/ECDSA-certifikat inte utfärdas till prenumeranter på grund av denna kända inkompatibilitet och risk.
  • Kodsignering stöder inte ECC eller nycklar > 4096

C. Krav för återkallande

  1. Certifikatutfärdare måste ha en dokumenterad återkallningsprincip och måste ha möjlighet att återkalla eventuella certifikat som det utfärdar.

  2. KRAV för OCSP-svarare: a. Minsta giltighet på åtta (8) timmar; Maximal giltighet på sju (7) dagar; och b. Nästa uppdatering måste vara tillgänglig minst åtta (8) timmar innan den aktuella perioden upphör att gälla. Om giltigheten är mer än 16 timmar måste nästa uppdatering vara tillgänglig 1/2 giltighetsperioden.

  3. CRL-rekommendationer när OCSP inte finns: a. Bör innehålla Microsoft-specifikt tillägg 1.3.6.1.4.1.311.21.4 (Nästa CRL-publicering). b. Ny CRL ska vara tillgänglig vid publiceringstillfället för nästa CRL. c. Den maximala storleken på CRL-filen (fullständig CRL eller partitionerad CRL) får inte överstiga 10 M.

    Kommentar

    Målet med avsnitt 3.C.3 – CRL-rekommendationer när OCSP inte finns är att tillhandahålla täckning för slutanvändare vid massåterkallning.

  4. Certifikatutfärdare får inte använda rotcertifikatet för att utfärda slutentitetscertifikat.

  5. Om en certifikatutfärdare utfärdar kodsigneringscertifikat måste den använda en tidsstämpelutfärdare som uppfyller RFC 3161, "Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)."

D. Krav för rotcertifikat för kodsignering

  1. Rotcertifikat som stöder användning av kodsignering kan tas bort från distributionen av programmet 10 år från distributionsdatumet för ett ersättningsrotcertifikat eller tidigare, om ca:n begär det.
  2. Rotcertifikat som finns kvar i distributionen för att endast stödja användning av kodsignering utöver algoritmens säkerhetslivslängd (t.ex. RSA 1024 = 2014, RSA 2048 = 2030) kan anges till "inaktivera" i Windows 10-operativsystemet.
  3. Från och med februari 2024 kommer Microsoft inte längre att acceptera eller känna igen ev-kodsigneringscertifikat, och CCADB kommer att upphöra att acceptera ev-kodsigneringsgranskningar. Från och med augusti 2024 tas alla EV Code Signing OIDs bort från befintliga rötter i Microsoft Trusted Root Program och alla kodsigneringscertifikat behandlas lika.

E. EKU-krav

  1. Certifikatutfärdare måste ange en affärsmotivering för alla EKU:er som tilldelats rotcertifikatet. Motiveringen kan vara i form av offentliga bevis för en aktuell verksamhet med utfärdande av certifikat av en typ eller typ, eller en affärsplan som visar en avsikt att utfärda dessa certifikat på kort sikt (inom ett år efter programmets distribution av rotcertifikat).

  2. Microsoft aktiverar endast följande EKU:er:

    1. Serverautentisering =1.3.6.1.5.5.7.3.1
    2. Klientautentisering =1.3.6.1.5.5.7.3.2
    3. Säker e-post-EKU=1.3.6.1.5.5.7.3.4
    4. Tidsstämpling av EKU=1.3.6.1.5.5.7.3.8
    5. Dokumentsignering EKU=1.3.6.1.4.1.311.10.3.12
    • Den här EKU:n används för signering av dokument i Office. Det krävs inte för andra användningar av dokumentsignering.

F. Windows 10 Kernel Mode Code Signing (KMCS) Krav

Windows 10 har ökade krav för att validera drivrutiner i kernelläge. Drivrutiner måste signeras av både Microsoft och en programpartner med hjälp av utökade valideringskrav. Alla utvecklare som vill ha sina kernellägesdrivrutiner inkluderade i Windows måste följa de procedurer som beskrivs av Microsofts maskinvaruutvecklingsteam. Mer information finns i Partnercenter för Windows-maskinvara.