Sdílet prostřednictvím

Požadavky na program – Důvěryhodný kořenový program Microsoftu

1. Úvod

Program kořenových certifikátů společnosti Microsoft podporuje distribuci kořenových certifikátů a umožňuje zákazníkům důvěřovat produktům Windows. Tato stránka popisuje obecné a technické požadavky programu.

Poznámka:

2. Pokračující požadavky programu

Požadavky auditu

  1. Účastníci programu musí poskytnout Microsoftu důkaz o opravňujícím auditu (viz https://aka.ms/auditreqs) pro každý kořenový, neomezený podřízenou certifikační autoritu a křížově podepsaný certifikát, a to před zahájením obchodních operací a poté každoročně.
  2. Účastníci programu musí převzít odpovědnost za to, že všechny nekontrénované podřízené certifikační autority a křížově podepsané certifikáty splňují požadavky na audit programu.
  3. Certifikační autority musí zveřejnit všechny zprávy o auditu pro neomezené podřízené certifikační autority.
  4. Poskytovatelé certifikační autority musí zajistit, aby kořenové certifikační autority s podporou S/MIME a všechny podřízené certifikační autority schopné vydávat certifikáty S/MIME byly a budou i nadále auditovány vůči nejnovější verzi minimálně jedné z následujících sad kritérií. K tomuto auditování musí dojít alespoň jednou za rok. Počáteční období auditu nesmí začínat nejpozději do 1. září 2023.
    • WebTrust Principles and Criteria for Certification Authorities – S/MIME
    • ETSI EN 119 411-6 LCP, NCP nebo NCP+

Požadavky na komunikaci a zpřístupnění

  1. Účastníci programu musí microsoftu poskytnout identity alespoň dvou důvěryhodných agentů, aby sloužily jako zástupci programu a jeden obecný e-mailový alias. Účastníci programu musí společnost Microsoft informovat o tom, pokud dojde k odebrání nebo přidání personálu jako důvěryhodných agentů. Účastníci programu souhlasí s přijímáním oznámení e-mailem a musí společnosti Microsoft poskytnout e-mailovou adresu, aby mohli dostávat oficiální oznámení. Účastníci programu musí souhlasit s tím, že oznámení platí, když Microsoft pošle e-mail nebo oficiální dopis. Nejméně jeden z poskytnutých kontaktů nebo aliasů by měl být nepřetržitě monitorovaným komunikačním kanálem pro žádosti o odvolání nebo jiné situace řešení incidentů.

  2. Účastník programu musí každoročně zpřístupnit Microsoftu úplnou hierarchii infrastruktury veřejných klíčů, zahrnující neomezené podřízené certifikační autority, křížově podepsané neregistrované kořenové certifikační autority, podřízené certifikační autority, rozšířitelné klíče pro použití (EKU) a omezení certifikátů, včetně certifikátů vydaných certifikačním autoritám provozovaným externími třetími stranami v rámci CCADB. Účastníci programu musí mít tyto informace přesné v CCADB, když dojde ke změnám. Pokud podřízená certifikační autorita není veřejně zpřístupněná nebo auditovaná, musí být omezená doménou.

  3. Účastníci programu musí Microsoft informovat e-mailem alespoň 120 dní před převodem vlastnictví registrované kořenové nebo podřízené certifikační autority, která je propojena s registrovaným kořenovým certifikátem, na jinou entitu nebo osobu.

  4. Kód důvodu musí být součástí odvolání zprostředkujících certifikátů. Certifikační autority musí aktualizovat DATABÁZI CCADB při odvolání zprostředkujících certifikátů do 30 dnů.

  5. Účastníci Programu souhlasí s tím, že společnost Microsoft může kontaktovat zákazníky, o nichž Microsoft věří, že budou podstatně ovlivněni připravovaným odebráním kořenové certifikační autority z Programu.

Další požadavky

  1. Komerční certifikační autority nemusí do programu zaregistrovat kořenovou certifikační autoritu, která má být primárně důvěryhodná interně v rámci organizace (tj. podnikových certifikačních autorit).

  2. Pokud certifikační autorita používá subdodavatele k provozování jakéhokoliv aspektu svého podnikání, certifikační autorita převezme odpovědnost za obchodní operace subdodavatele.

  3. Pokud Společnost Microsoft podle vlastního uvážení určí certifikát, jehož použití nebo atributy jsou určeny v rozporu s cíli důvěryhodného kořenového programu, společnost Microsoft oznámí příslušné certifikační autoritě a požádá o odvolání certifikátu. Certifikační autorita musí certifikát odvolat nebo požádat o výjimku od Microsoftu do 24 hodin od přijetí oznámení microsoftu. Společnost Microsoft zkontroluje předložené materiály a informuje certifikační autoritu o konečném rozhodnutí udělit nebo zamítnout výjimku podle vlastního uvážení. V případě, že Microsoft výjimku neudělí, musí certifikační autorita odvolat certifikát do 24 hodin od odepření výjimky.

3. Technické požadavky programu

Všechny certifikační autority v programu musí splňovat technické požadavky programu. Pokud Microsoft zjistí, že certifikační autorita není v souladu s následujícími požadavky, Microsoft ji z programu vyloučí.

A. Kořenové požadavky

  1. Kořenové certifikáty musí být certifikáty x.509 v3.
    1. Atribut CN musí identifikovat vydavatele a musí být jedinečný.
    2. Atribut CN musí být v jazyce, který je vhodný pro trh certifikační autority a čitelný typickým zákazníkem na daném trhu.
    3. Rozšíření základních omezení: musí být cA=true.
    4. Rozšíření Key Usage musí být přítomné a musí být označeno jako kritické. Pozice bitů pro KeyCertSign a cRLSign musí být nastaveny. Pokud se k podepisování odpovědí OCSP používá privátní klíč kořenové certifikační autority, musí být nastaven bit digitalSignature.
      • Velikosti kořenových klíčů musí splňovat požadavky uvedené níže v části Požadavky na podpis.
  2. Certifikáty, které se mají přidat do důvěryhodného kořenového úložiště, musí být kořenové certifikáty podepsané svým držitelem.
  3. Nově vydané kořenové certifikační autority musí být platné od data podání minimálně osm let a maximálně 25 let.
  4. Zúčastněné kořenové certifikační autority nemusí vydávat nové 1024bitové certifikáty RSA z kořenových certifikátů, na které se vztahují tyto požadavky.
  5. Všechny vydávající certifikáty certifikační autority musí obsahovat buď rozšíření CDP s platným seznamem CRL, nebo rozšíření AIA na OCSP odpovídače. Certifikát koncové entity může obsahovat rozšíření AIA s platnou adresou URL OCSP a/nebo rozšíření CDP odkazující na platný koncový bod HTTP obsahující seznam CRL. Pokud není zahrnuta přípona AIA s platnou adresou URL OCSP, výsledný soubor CRL by měl být <10 MB.
  6. Názvy privátních klíčů a subjektů musí být jedinečné pro každý kořenový certifikát; opakované použití privátních klíčů nebo názvů subjektů v následných kořenových certifikátech stejné certifikační autority může vést k neočekávaným problémům s řetězení certifikátů. Certifikační autority musí vygenerovat nový klíč a použít nový název subjektu při generování nového kořenového certifikátu před distribucí od Microsoftu.
  7. Certifikační autority státní správy musí omezit ověřování serveru na domény nejvyšší úrovně vydané vládou a mohou vydávat jiné certifikáty pouze pro kódy zemí ISO3166, nad kterými má země suverénní kontrolu (viz https://aka.ms/auditreqs část III definice "certifikační autority státní správy"). Tyto vládou vydané TLD jsou uvedeny v příslušné smlouvě každé certifikační autority.
  8. Vystavování certifikátů certifikační autority, které se zřetězují s účastí kořenové certifikační autority, musí oddělit ověřování serveru, S/MIME, podepisování kódu a použití časového razítka. To znamená, že jedna vydávající certifikační autorita nesmí kombinovat ověřování serveru s S/MIME, podepisováním kódu nebo časovým razítkem EKU. Pro každé použití se musí použít samostatná mezivrstva.
  9. Certifikáty koncových entit musí splňovat požadavky na typ algoritmu a velikost klíče pro certifikáty odběratele uvedené v dodatku A standardních požadavků fóra CAB umístěných na https://cabforum.org/baseline-requirements-documents/adrese .
  10. Certifikační autority musí deklarovat jeden z následujících identifikátorů OID zásad v koncovém certifikátu rozšíření Zásad certifikátu.
    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. Podpis kódu bez EV 2.23.140.1.4.1.
    6. Ověření poštovní schránky pomocí S/MIME Legacy 2.23.140.1.5.1.1.
    7. Ověření poštovní schránky S/MIME pro vícenásobné použití 2.23.140.1.5.1.2.
    8. Poštovní schránka S/MIME byla ověřena striktně 2.23.140.1.5.1.3.
    9. Organizace S/MIME byla ověřená starší verzí 2.23.140.1.5.2.1.
    10. S/MIME certifikát s ověřením organizace Multipurpose 2.23.140.1.5.2.2.
    11. Organizace S/MIME ověřila striktní 2.23.140.1.5.2.3.
    12. Ověřený sponzor S/MIME Legacy 2.23.140.1.5.3.1.
    13. S/MIME sponzor Ověřený Víceúčelový 2.23.140.1.5.3.2.
    14. S/MIME sponzor Validovaný Striktní 2.23.140.1.5.3.3.
    15. Individuální ověření S/MIME starší verze 2.23.140.1.5.4.1
    16. Individuální S/MIME ověřený Multipurpose 2.23.140.1.5.4.2.
    17. Individuálně ověřené S/MIME striktní 2.23.140.1.5.4.3.
  11. Od srpna 2024 budou všechny vlastní identifikátory OID EV SSL spravované programem Trusted Root a našimi příslušnými nástroji odebrány a nahrazeny identifikátorem OID EV SSL v souladu s CA/B Forum (2.23.140.1.1). Tým Microsoft Edge implementuje v prohlížeči kontroly identifikátorů OID PROTOKOLU EV SSL (2.23.140.1.1), takže ostatní identifikátory OID SSL EV se už nebudou přijímat, aby byly v souladu s Edgem a zabránily nekompatibilitě.
  12. Certifikační autority nesmí mít na svém kořenovém certifikátu více než 2 identifikátory OID.
  13. Certifikáty koncových entit, které obsahují rozšíření základních omezení v souladu s dokumentem IETF RFC 5280, musí mít pole cA nastavené na HODNOTU FALSE a pole pathLenConstraint musí chybět.
  14. Certifikační autorita musí technicky omezit respondér OCSP tak, aby jediným povoleným EKU bylo podepisování OCSP.
  15. Certifikační autorita musí být schopná odvolat certifikát k určitému datu, jak požaduje Microsoft.

B. Požadavky na podpis

Algoritmus Všechna použití kromě podepisování kódu a časového razítka Podepisování kódu a použití časového razítka
Hashovací algoritmy SHA2 (SHA256, SHA384, SHA512) SHA2 (SHA256, SHA384, SHA512)
šifrování RSA 2048 4096 (pouze nové kořeny)
ECC / ECDSA NIST P-256, P-384, P-521 Nepodporuje se

Poznámka:

  • V systému Windows a novějších funkcích zabezpečení systému Windows nejsou podporovány podpisy používající kryptografii elipsické křivky (ECC), jako je ECDSA. Uživatelé využívající tyto algoritmy a certifikáty budou čelit různým chybám a potenciálním bezpečnostním rizikům. Důvěryhodný kořenový program Společnosti Microsoft doporučuje, aby certifikáty ECC/ECDSA neměly být vystaveny odběratelům kvůli této známé nekompatibilitě a riziku.
  • Podepisování kódu nepodporuje ECC ani klíče > 4096

C. Požadavky na odvolání

  1. Certifikační autority musí mít zdokumentovanou zásadu odvolání a musí mít možnost odvolat všechny certifikáty, které vystavuje.

  2. Požadavky reagátora OCSP: a. Minimální platnost osmi (8) hodin; Maximální platnost sedmi (7) dnů; a b. Další aktualizace musí být k dispozici alespoň osm (8) hodin před vypršením aktuálního období. Pokud je platnost delší než 16 hodin, musí být další aktualizace k dispozici v 1/2 období platnosti.

  3. Doporučení pro CRL, pokud není k dispozici OCSP: a. Mělo by obsahovat rozšíření specifické pro Microsoft 1.3.6.1.4.1.311.21.4 (další publikování seznamu CRL). b. Nový seznam CRL by měl být k dispozici v čase příštího publikování seznamu CRL. c. Maximální velikost souboru CRL (úplný CRL nebo dělený CRL) by neměla překročit 10 M.

    Poznámka:

    Cílem oddílu 3.C.3- Doporučení CRL, pokud není k dispozici OCSP, je poskytnout pokrytí koncovým uživatelům v případech hromadného odvolání.

  4. Certifikační autorita nesmí používat kořenový certifikát k vydávání certifikátů koncových entit.

  5. Pokud certifikační autorita vydává certifikáty pro podepisování kódu, musí používat autoritu časového razítka, která splňuje požadavky dokumentu RFC 3161, "Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)."

D. Požadavky na kořenový certifikát pro podepisování kódu

  1. Kořenové certifikáty, které podporují použití podepisování kódu, mohou být odebrány z distribuce programem 10 let od data distribuce náhradního kořenového certifikátu pro vrácení zpět nebo dříve, pokud o to certifikační autorita požádá.
  2. Kořenové certifikáty, které zůstávají v distribuci, aby podporovaly použití pouze podepisování kódu nad rámec doby životnosti zabezpečení algoritmu (např. RSA 1024 = 2014, RSA 2048 = 2030), mohou být v operačním systému Windows 10 nastaveny na zákaz.
  3. Od února 2024 už Microsoft nebude přijímat ani rozpoznávat podpisové certifikáty EV kódu a CCADB přestane přijímat audity podepisování kódu EV. Od srpna 2024 budou všechny identifikátory OID podepisování kódu EV odebrány z existujících kořenových certifikátů v programu Microsoft Trusted Root Program a všechny certifikáty podepisování kódu budou považovány za stejné.

E. Požadavky na EKU

  1. Certifikační autority musí poskytnout obchodní odůvodnění všech jednotek EKU přiřazených k jejich kořenovému certifikátu. Odůvodnění může být ve formě veřejných důkazů současné činnosti vydávání certifikátů typu nebo typů nebo obchodního plánu, který demonstruje záměr vydávat tyto certifikáty v blízké době (do jednoho roku distribuce kořenových certifikátů programem).

  2. Microsoft povolí pouze následující EKU:

    1. Ověřování serveru =1.3.6.1.5.5.7.3.1
    2. Ověřování klienta =1.3.6.1.5.5.7.3.2
    3. Zabezpečený e-mail EKU=1.3.6.1.5.5.7.3.4
    4. Časové razítko EKU=1.3.6.1.5.5.7.3.8
    5. Podepisování dokumentů EKU=1.3.6.1.4.1.311.10.3.12
    • Tento EKU se používá k podepisování dokumentů v rámci Office. Nevyžaduje se pro jiné použití podepisování dokumentů.

F. Požadavky na podepisování kódu v režimu jádra Windows 10 (KMCS)

Windows 10 má zvýšené požadavky na ověření ovladačů režimu jádra. Ovladače musí být podepsány microsoftem i partnerem programu pomocí požadavků rozšířeného ověřování. Všichni vývojáři, kteří chtějí mít ovladače v režimu jádra zahrnuté ve Windows, musí dodržovat postupy popsané týmem Microsoft Hardware Development Team. Další informace najdete v Partner Center pro Windows Hardware.

  • Last updated on