Programkövetelmények – Microsoft Megbízható gyökérprogram

1. Bevezetés

A Microsoft főtanúsítvány-program támogatja a főtanúsítványok terjesztését, így az ügyfelek megbíznak a Windows-termékekben. Ez az oldal a program általános és műszaki követelményeit ismerteti.

2. A programra vonatkozó követelmények folytatása

Naplózási követelmények

1. A program résztvevőinek a kereskedelmi műveletek végrehajtása előtt és ezt követően évente meg kell adniuk a Microsoftnak a minősített auditot (lásd https://aka.ms/auditreqs) minden egyes gyökér-, nem korlátozott alárendelt hitelesítésszolgáltató- és keresztaláírt tanúsítvány esetében.
2. A program résztvevőinek felelősséget kell vállalniuk annak biztosításáért, hogy minden be nem kötött alárendelt hitelesítésszolgáltató és keresztaláírt tanúsítvány megfeleljen a program auditálási követelményeinek.
3. A hitelesítésszolgáltatóknak nyilvánosan közzé kell tenni a nem ellenőrzött alárendelt hitelesítésszolgáltatókra vonatkozó összes auditjelentést.
4. A ca-szolgáltatóknak gondoskodniuk kell arról, hogy az S/MIME-kompatibilis legfelső szintű hitelesítésszolgáltatók és az S/MIME-tanúsítványok kiállítására képes összes alárendelt hitelesítésszolgáltató az alábbi feltételek közül legalább az egyik legújabb verziójával legyen és továbbra is auditálva legyenek. A naplózásnak évente legalább egyszer meg kell történnie. A kezdeti ellenőrzési időszaknak legkésőbb 2023. szeptember 1-je után meg kell kezdődnie.
   
   • WebTrust-alapelvek és kritériumok a hitelesítésszolgáltatók számára – S/MIME
     
   • ETSI EN 119 411-6 LCP, NCP vagy NCP+
     

Kommunikációs és közzétételi követelmények

4. A program résztvevőinek legalább két "megbízható ügynök" identitását meg kell adniuk a Microsoftnak, hogy a program képviselőiként és egy általános e-mail-aliasként szolgáljanak. A program résztvevőinek tájékoztatniuk kell a Microsoftot a személyzet megbízható ügynökként való eltávolításáról vagy felvételéről. A program résztvevői megállapodnak abban, hogy e-mailben értesítést kapnak, és meg kell adniuk a Microsoftnak egy e-mail-címet a hivatalos értesítések fogadásához. A program résztvevőinek el kell fogadniuk, hogy az értesítés akkor lép érvénybe, ha a Microsoft e-mailt vagy hivatalos levelet küld. Legalább az egyik megadott partnernek vagy aliasnak 24/7-es figyelt kommunikációs csatornának kell lennie a visszavonási kérelmekhez vagy más incidenskezelési helyzetekhez.

5. A program résztvevőjének évente közzé kell tennie teljes PKI-hierarchiáját (nem tagolt alárendelt hitelesítésszolgáltató, kereszttáblás, nem regisztrált legfelső szintű hitelesítésszolgáltatók, alárendelt hitelesítésszolgáltatók, EKU-k, tanúsítványkorlátozások) a Microsoftnak, beleértve a CCADB-n belül külső harmadik felek által üzemeltetett hitelesítésszolgáltatóknak kibocsátott tanúsítványokat is. A program résztvevőinek pontosnak kell lenniük a CCADB-ben, amikor változások történnek. Ha egy alárendelt hitelesítésszolgáltatót nem fednek fel nyilvánosan vagy nem naplóznak, tartományra korlátozottnak kell lennie.

6. A program résztvevőinek legalább 120 nappal azelőtt e-mailben kell tájékoztatniuk a Microsoftot, hogy átadják a regisztrált legfelső szintű vagy alárendelt hitelesítésszolgáltató tulajdonjogát, amely egy regisztrált gyökerhez láncolt egy másik entitáshoz vagy személyhez.

7. Az okkódnak szerepelnie kell a köztes tanúsítványok visszavonásaiban. A hitelesítésszolgáltatóknak frissítenie kell a CCADB-t, amikor 30 napon belül visszavonják a köztes tanúsítványokat.

8. A program résztvevői megállapodnak abban, hogy a Microsoft kapcsolatba léphet olyan ügyfelekkel, akikről a Microsoft úgy véli, hogy jelentős hatással lehet egy legfelső szintű hitelesítésszolgáltató programból való függőben lévő eltávolítása.

Egyéb követelmények

9. A kereskedelmi hitelesítésszolgáltatók nem regisztrálhatnak legfelső szintű hitelesítésszolgáltatót a programba, amely elsősorban egy szervezeten belül (azaz vállalati hitelesítésszolgáltatókon) belül megbízhatónak minősül.

10. Ha egy hitelesítésszolgáltató alvállalkozót használ üzleti tevékenységének bármely területének működtetésére, a hitelesítésszolgáltató felelősséget vállal az alvállalkozó üzleti műveleteiért.

11. Ha a Microsoft saját belátása szerint azonosít egy tanúsítványt, amelynek használati vagy attribútumai a megbízható legfelső szintű program célkitűzéseivel ellentétesnek minősülnek, a Microsoft értesíti a felelős hitelesítésszolgáltatót, és kéri, hogy vonja vissza a tanúsítványt. A hitelesítésszolgáltatónak a Microsoft értesítésétől számított 24 órán belül vissza kell vonnia a tanúsítványt, vagy kivételt kell kérnie a Microsofttól. A Microsoft áttekinti a benyújtott anyagokat, és saját belátása szerint tájékoztatja a CA-t a kivétel megadásáról vagy elutasításáról. Abban az esetben, ha a Microsoft nem adja meg a kivételt, a hitelesítésszolgáltatónak a kivétel elutasításától számított 24 órán belül vissza kell vonnia a tanúsítványt.

3. A program műszaki követelményei

A program minden hitelesítésszolgáltatójának meg kell felelnie a program műszaki követelményeinek. Ha a Microsoft megállapítja, hogy a hitelesítésszolgáltató nem felel meg az alábbi követelményeknek, a Microsoft kizárja ezt a hitelesítésszolgáltatót a programból.

A. Alapvető követelmények

1. A főtanúsítványoknak x.509 v3-tanúsítványoknak kell lenniük.
   1. A CN attribútumnak azonosítania kell a közzétevőt, és egyedinek kell lennie.
   2. A CN-attribútumnak olyan nyelven kell lennie, amely megfelel a hitelesítésszolgáltató piacának, és amelyet az adott piacon egy tipikus ügyfél olvashat.
   3. Alapvető korlátozások bővítménye: cA=true értéknek kell lennie.
   4. A kulcshasználati bővítménynek jelen kell lennie, és kritikus fontosságúnak kell lennie. A KeyCertSign és a cRLSign bitpozícióit be kell állítani. Ha a legfelső szintű hitelesítésszolgáltató titkos kulcsát használja az OCSP-válaszok aláírásához, akkor a digitalSignature bitet be kell állítani.
      • A gyökérkulcs-méreteknek meg kell felelniük az alábbi "Aláírási követelmények" című cikkben ismertetett követelményeknek.
2. A megbízható legfelső szintű tárolóhoz hozzáadni kívánt tanúsítványoknak önaláírt főtanúsítványoknak kell lenniük.
3. Az újonnan kivert legfelső szintű hitelesítésszolgáltatóknak legalább nyolc évig, de legfeljebb 25 évig érvényesnek kell lenniük a beküldés időpontjától kezdve.
4. Előfordulhat, hogy a részt vevő legfelső szintű hitelesítésszolgáltatók nem bocsátanak ki új, 1024 bites RSA-tanúsítványokat az e követelmények hatálya alá tartozó gyökerekből.
5. Minden kiállító hitelesítésszolgáltatói tanúsítványnak tartalmaznia kell egy érvényes CRL-t és/vagy egy OCSP-válaszadóhoz tartozó AIA-kiterjesztést tartalmazó CDP-bővítményt. A végfelhasználói tanúsítvány tartalmazhat érvényes OCSP URL-címmel rendelkező AIA-bővítményt és/vagy a CRL-t tartalmazó érvényes HTTP-végpontra mutató CDP-bővítményt. Ha egy érvényes OCSP URL-címmel rendelkező AIA-bővítmény NEM szerepel, akkor az eredményül kapott CRL-fájlnak 10 MB-nak kell lennie <.
6. A titkos kulcsoknak és a tulajdonosneveknek főtanúsítványonként egyedinek kell lenniük; a titkos kulcsok vagy a tulajdonosnevek ugyanazon hitelesítésszolgáltató általi későbbi főtanúsítványokban való újbóli használata váratlan tanúsítványláncolási problémákat okozhat. A hitelesítésszolgáltatóknak új kulcsot kell létrehozniuk, és új tulajdonosnevet kell alkalmazniuk, amikor új főtanúsítványt hoznak létre a Microsoft általi terjesztés előtt.
7. A kormányzati hitelesítésszolgáltatóknak a kiszolgálóhitelesítést kormányzati kiadású legfelső szintű tartományokra kell korlátozniuk, és más tanúsítványokat csak azon ISO3166 országkódokhoz adhatnak ki, amelyek felett az ország szuverén ellenőrzést tart (a "Kormányzati hitelesítésszolgáltató" definícióját lásd https://aka.ms/auditreqs a III. szakaszban). Ezekre a kormányzati kiadású TLD-kre az egyes hitelesítésszolgáltatói szerződések hivatkoznak.
8. A résztvevő legfelső szintű hitelesítésszolgáltatóhoz láncoló hitelesítésszolgáltatói tanúsítványoknak külön kiszolgálóhitelesítést, S/MIME-t, kódaláírást és időbélyegzést kell használniuk. Ez azt jelenti, hogy egyetlen kiállító hitelesítésszolgáltató nem kombinálhatja a kiszolgálóhitelesítést az S/MIME-vel, a kódaláírással vagy az EKU időbélyegzésével. Minden használati esethez külön köztesetet kell használni.
9. A végfelhasználói tanúsítványoknak meg kell felelniük az előfizetői tanúsítványok algoritmustípusára és kulcsméretére vonatkozó követelményeknek, amely a CAB Fórum alapkonfigurációs https://cabforum.org/baseline-requirements-documents/követelményeinek A függelékében található.
10. A hitelesítésszolgáltatóknak a tanúsítványházirend-bővítmény végfelhasználói tanúsítványában az alábbi házirend-azonosítók egyikét kell deklarálniuk.
    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. Nem EV-kód aláírása 2.23.140.1.4.1.
    6. S/MIME postaláda érvényesített örökölt 2.23.140.1.5.1.1.
    7. S/MIME postaláda érvényesített többcélú 2.23.140.1.5.1.2.
    8. S/MIME postaláda érvényesített szigorú 2.23.140.1.5.1.3.
    9. S/MIME-szervezet által hitelesített örökölt 2.23.140.1.5.2.1.
    10. S/MIME Organization Validated Multipurpose 2.23.140.1.5.2.2.
    11. Az S/MIME-szervezet a szigorú 2.23.140.1.5.2.3-at érvényesítette.
    12. S/MIME Sponsor validált örökölt 2.23.140.1.5.3.1.
    13. S/MIME Sponsor Validated Multipurpose 2.23.140.1.5.3.2.
    14. S/MIME Sponsor Valided 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 Individual Validated Strict 2.23.140.1.5.4.3.
11. 2024 augusztusától a megbízható gyökérprogram és a megfelelő eszközkészlet által kezelt egyéni EV SSL-azonosítók el lesznek távolítva, és a ca/B fórumnak megfelelő EV SSL OID -ra (2.23.140.1.1.1) kerülnek. A Microsoft Edge csapata a böngészőben végrehajtja az EV SSL OID (2.23.140.1.1) ellenőrzését, így más EV SSL-azonosítók már nem lesznek elfogadva az Edge-hez való igazodás és az inkompatibilitás elkerülése érdekében.
12. A hitelesítésszolgáltatók legfeljebb 2 azonosítót alkalmazhatnak a főtanúsítványukra.
13. Azok a végfelhasználói tanúsítványok, amelyek az IETF RFC 5280-nak megfelelően alapszintű kényszerkiterjesztést tartalmaznak, a cA mezőt FALSE értékre kell állítani, a pathLenConstraint mezőnek pedig nem kell szerepelnie.
14. A hitelesítésszolgáltatónak technikailag korlátoznia kell egy OCSP-válaszadót, hogy az egyetlen engedélyezett termékváltozat az OCSP-aláírás legyen.
15. A hitelesítésszolgáltatónak képesnek kell lennie arra, hogy visszavonjon egy tanúsítványt a Microsoft által kért meghatározott dátumig.

B. Aláírási követelmények

Ne feledje:

• A háromliptikus íves titkosítást (ECC) használó aláírások, például az ECDSA nem támogatottak a Windowsban és az újabb Windows biztonsági funkciókban. Az algoritmusokat és tanúsítványokat használó felhasználók különböző hibákba és potenciális biztonsági kockázatokba ütközhetnek. A Microsoft megbízható gyökérprogramja azt javasolja, hogy az ECC/ECDSA-tanúsítványokat ne lehessen kibocsátani az előfizetőknek az ismert kompatibilitás és kockázat miatt.
• A kódaláírás nem támogatja az ECC-t vagy a 4096-os kulcsokat >

C. Visszavonási követelmények

1. A hitelesítésszolgáltatóknak dokumentált visszavonási szabályzattal kell rendelkezniük, és képesnek kell lenniük a kibocsátott tanúsítványok visszavonására.

2. OCSP-válaszadók követelményei: a. Legalább nyolc (8) óra érvényesség; Hét (7) nap maximális érvényessége; és b. A következő frissítésnek legalább nyolc (8) órával az aktuális időszak lejárta előtt elérhetővé kell lennie. Ha az érvényesség több mint 16 óra, akkor a következő frissítésnek az érvényességi időszak 1/2-ével kell elérhetőnek lennie.

3. CRL-javaslatok, ha az OCSP nincs jelen: a. A Microsoft-specifikus bővítménynek tartalmaznia kell az 1.3.6.1.4.1.311.21.4-et (következő CRL-közzététel). b. Az új CRL-nek elérhetőnek kell lennie a következő CRL-közzétételi időpontban. c. A CRL-fájl maximális mérete (teljes CRL vagy particionált CRL) nem haladhatja meg a 10 M-t.

   Feljegyzés

   A 3.C.3– CRL-javaslatok célja, ha az OCSP nem jelenik meg, a végfelhasználók lefedettségének biztosítása tömeges visszavonás esetén.

4. A hitelesítésszolgáltató nem használhatja a főtanúsítványt a végfelhasználói tanúsítványok kiállításához.

5. Ha egy hitelesítésszolgáltató kódaláíró tanúsítványokat ad ki, az RFC 3161-nek megfelelő időbélyeg-szolgáltatót kell használnia, amely megfelel az "Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP) protokollnak".

D. Kódaláíró főtanúsítvány követelményei

1. A kódaláírást támogató főtanúsítványokat a program eltávolíthatja a terjesztésből a helyettesítő rollover főtanúsítvány terjesztésétől számított 10 évig, vagy előbb, ha a hitelesítésszolgáltató kéri.
2. Azok a főtanúsítványok, amelyek továbbra is terjesztve maradnak, és csak az algoritmus biztonsági élettartamán túli kódaláírást támogatnak (pl. RSA 1024 = 2014, RSA 2048 = 2030) a Windows 10 operációs rendszerben "letiltás" értékre állíthatók.
3. 2024 februárjától a Microsoft már nem fogadja el vagy ismeri fel az EV-kódaláíró tanúsítványokat, és a CCADB nem fogadja el az EV-kódaláírási auditokat. 2024 augusztusától minden EV-kódaláíró azonosító el lesz távolítva a Microsoft megbízható gyökérprogramjának meglévő gyökeréből, és minden kódaláíró tanúsítványt egyformán kezelünk.

E. EKU-követelmények

1. A hitelesítésszolgáltatóknak üzleti indoklást kell adniuk a főtanúsítványukhoz rendelt összes EKU-ra vonatkozóan. Az indoklás lehet olyan nyilvános bizonyíték formájában, amely egy jelenlegi vállalkozásnak egy típus vagy típus tanúsítványának kiállítására irányul, vagy olyan üzleti terv formájában, amely azt mutatja, hogy a tanúsítványokat a közeljövőben ki kívánja adni (a program által a főtanúsítvány-terjesztést követő egy éven belül).

2. A Microsoft csak a következő EKU-kat engedélyezi:

   1. Kiszolgálóhitelesítés =1.3.6.1.5.5.7.3.1
   2. Ügyfél-hitelesítés =1.3.6.1.5.5.7.3.2
   3. Biztonságos e-mail EKU=1.3.6.1.5.5.7.3.4
   4. Időbélyegzés EKU=1.3.6.1.5.5.7.3.8
   5. Dokumentum-aláírási termékváltozat=1.3.6.1.4.1.311.10.3.12
   • Ez az EKU az Office-on belüli dokumentumok aláírására szolgál. Más dokumentum-aláírási célokhoz nem szükséges.

F. A Windows 10 kernelmódú kódaláírási (KMCS) követelményei

A Windows 10 magasabb követelményekkel rendelkezik a kernelmódú illesztőprogramok ellenőrzéséhez. Az illesztőprogramokat a Microsoftnak és egy programpartnernek is alá kell írnia kiterjesztett érvényesítési követelményekkel. Minden fejlesztőnek, aki a Windows rendszermag módú illesztőprogramjait szeretné tartalmazni, a Microsoft hardverfejlesztési csapata által ismertetett eljárásokat kell követnie. További információt a Windows-hardver partnerközpontjában talál.