Sdílet prostřednictvím

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

  • Článek

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čování požadavků na program

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ý, nekonkurčovaný podřízený certifikační autorita a křížově podepsaný certifikát, a to před ročním provedením obchodních operací a následně.
  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í veřejně zveřejnit všechny sestavy auditu pro nekontrénované 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 odebrání nebo přidání pracovníků jako důvěryhodného agenta. Úč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 komunikační kanál s 24/7 monitorovaným komunikačním kanálem pro žádosti o odvolání nebo jiné situace řízení incidentů.

  2. Účastník programu musí každoročně zpřístupnit microsoftu úplnou hierarchii infrastruktury veřejných klíčů (neomezený podřízený certifikační autorita, neregistrované kořenové certifikační autority, podřízené certifikační autority, podřízené certifikační autority, EKU, 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á se zřetězuje s zaregistrovaným kořenovým adresářem 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, kterým Microsoft věří, že může být podstatně ovlivněna nevyřízený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. Požadavky na kořen

  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. Musí být k dispozici rozšíření Použití klíče a musí být označené 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 popsané v části Požadavky na klíč.
  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ě vyražené kořenové certifikační autority musí být platné minimálně osm let a od data podání musí být 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 certifikáty koncových entit musí obsahovat rozšíření AIA s platnou adresou URL OCSP. Tyto certifikáty mohou také obsahovat rozšíření CDP, které obsahuje platnou adresu URL seznamu CRL. Všechny ostatní typy certifikátů musí obsahovat buď rozšíření AIA s adresou URL OCSP, nebo s příponou CDP s platnou adresou URL seznamu CRL.
  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 jednotky TLD vydané vládou se označují 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ý případ použití se musí použít samostatný zprostředkující.
  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ů identifikátorů OID zásad v certifikátu rozšíření Zásad certifikátů.
    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.
  11. Od srpna 2024 budou odebrány a nahrazeny všemi vlastními identifikátory OID PROTOKOLU EV SSL SSL (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 nemusí mít na kořenový certifikát 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 reagujícího 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
Algoritmy digest SHA2 (SHA256, SHA384, SHA512) SHA2 (SHA256, SHA384, SHA512)
RSA 2048 4096 (pouze nové kořeny)
ECC / ECDSA NIST P-256, P-384, P-521 NIST P-256, P-384, P-521

Poznámka: Podpisy používající kryptografii s eliptickou křivkou (ECC), jako je ECDSA, nejsou podporovány ve Windows a novějších funkcích zabezpečení Systému Windows. 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.

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. Certifikační autority, které vydávají certifikáty ověřování serveru, musí podporovat oba následující požadavky reagovacího programu OCSP:
    1. Minimální platnost osmi (8) hodin; maximální platnost sedmi (7) dnů.
    2. 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. Všechny certifikáty vydané od kořenové certifikační autority musí podporovat buď rozšíření distribučního bodu seznamu CRL, nebo AIA obsahující adresu URL respondéru OCSP.
  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á podpisové certifikáty kódu, musí používat autoritu časového razítka, která je v souladu s dokumentem 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 Partnerském centru pro hardware windows.