Wymagania dotyczące programu — zaufany program główny firmy Microsoft

1. Wprowadzenie

Program certyfikatów głównych firmy Microsoft obsługuje dystrybucję certyfikatów głównych, umożliwiając klientom zaufanie do produktów systemu Windows. Na tej stronie opisano ogólne i techniczne wymagania programu.

Uwaga

• Aby uzyskać informacje na temat najnowszych aktualizacji dostarczonych, zobacz https://aka.ms/rootupdates
• Oznacz tę stronę zakładką jako: https://aka.ms/RootCert

2. Dalsze wymagania dotyczące programu

Wymagania dotyczące inspekcji

1. Uczestnicy programu muszą dostarczyć firmie Microsoft dowód kwalifikowanej inspekcji (patrz https://aka.ms/auditreqs) dla każdego głównego, nieograniczonego podrzędnego urzędu certyfikacji i certyfikatu z podpisem krzyżowym, przed przeprowadzeniem operacji komercyjnych i następnie co roku.
2. Uczestnicy programu muszą przyjąć odpowiedzialność za zapewnienie, że wszystkie niepowiązane podrzędne urzędy certyfikacji i certyfikaty podpisane krzyżowo spełniają wymagania inspekcji programu.
3. Urzędy certyfikacji muszą publicznie ujawnić wszystkie raporty inspekcji dla nieuszkodzonych podrzędnych urzędów certyfikacji.
4. Dostawcy urzędu certyfikacji muszą zapewnić, że główne urzędy certyfikacji z włączoną funkcją S/MIME i wszystkie podrzędne urzędy certyfikacji zdolne do wystawiania certyfikatów S/MIME zostały poddane inspekcji co najmniej w najnowszej wersji jednego z poniższych zestawów kryteriów. Ta inspekcja musi odbywać się co najmniej raz w roku. Początkowy okres inspekcji musi rozpoczynać się nie później niż 1 września 2023 r.
   
   • Zasady i kryteria zaufania sieci Web dla urzędów certyfikacji — S/MIME
     
   • ETSI EN 119 411-6 LCP, NCP lub NCP+
     

Wymagania dotyczące komunikacji i ujawniania informacji

4. Uczestnicy programu muszą podać tożsamości firmy Microsoft co najmniej dwóch "zaufanych agentów", aby służyć jako przedstawiciele programu i jeden ogólny alias poczty e-mail. Uczestnicy programu muszą poinformować firmę Microsoft o usunięciu lub dodaniu personelu jako zaufanego agenta. Uczestnicy programu zgadzają się otrzymywać powiadomienia pocztą e-mail i muszą podać firmie Microsoft adres e-mail, aby otrzymywać oficjalne powiadomienia. Uczestnicy programu muszą wyrazić zgodę, że powiadomienie jest skuteczne, gdy firma Microsoft wysyła wiadomość e-mail lub oficjalny list. Co najmniej jeden z podanych kontaktów lub aliasów powinien być monitorowany kanał komunikacji 24/7 na potrzeby żądań odwołania lub innych sytuacji zarządzania zdarzeniami.

5. Uczestnik programu musi ujawnić pełną hierarchię PKI (niepodlegającego ograniczonemu podrzędnemu urzędowi certyfikacji, nierejestrowanemu głównemu urzędowi certyfikacji, podrzędnym urzędom certyfikacji, EKU, ograniczeniom certyfikatów) firmie Microsoft co roku, w tym certyfikatom wystawionym dla urzędów certyfikacji obsługiwanych przez zewnętrzne podmioty trzecie w programie CCADB. Uczestnicy programu muszą zachować te informacje dokładne w programie CCADB, gdy wystąpią zmiany. Jeśli podrzędny urząd certyfikacji nie został publicznie ujawniony lub poddany inspekcji, musi być ograniczony przez domenę.

6. Uczestnicy programu muszą poinformować firmę Microsoft pocztą e-mail co najmniej 120 dni przed przeniesieniem własności zarejestrowanego głównego lub podrzędnego urzędu certyfikacji, który tworzy łańcuchy do zarejestrowanego katalogu głównego do innej jednostki lub osoby.

7. Kod przyczyny musi być uwzględniony w odwołaniach dla certyfikatów pośrednich. Urzędy certyfikacji muszą zaktualizować program CCADB podczas odwoływanie jakichkolwiek certyfikatów pośrednich w ciągu 30 dni.

8. Uczestnicy programu zgadzają się, że firma Microsoft może skontaktować się z klientami, których firma Microsoft uważa, że może mieć znaczący wpływ na oczekujące usunięcie głównego urzędu certyfikacji z programu.

Inne wymagania

9. Komercyjne urzędy certyfikacji mogą nie rejestrować głównego urzędu certyfikacji do programu, który ma być przede wszystkim zaufany wewnętrznie w organizacji (tj. urzędy certyfikacji przedsiębiorstwa).

10. Jeśli urząd certyfikacji korzysta z podwykonawcy do obsługi jakiegokolwiek aspektu swojej działalności, urząd certyfikacji będzie ponosić odpowiedzialność za działalność podwykonawcy.

11. Jeśli firma Microsoft, według własnego uznania, identyfikuje certyfikat, którego użycie lub atrybuty są określane jako sprzeczne z celami zaufanego programu głównego, firma Microsoft powiadomi odpowiedzialnego urzędu certyfikacji i zażąda odwołania certyfikatu. Urząd certyfikacji musi odwołać certyfikat lub zażądać wyjątku od firmy Microsoft w ciągu 24 godzin od otrzymania powiadomienia firmy Microsoft. Firma Microsoft dokona przeglądu przesłanych materiałów i poinformuje urząd certyfikacji o ostatecznej decyzji o przyznaniu lub odmowie wyjątku według własnego uznania. W przypadku, gdy firma Microsoft nie udziela wyjątku, urząd certyfikacji musi odwołać certyfikat w ciągu 24 godzin od odmowy wyjątku.

---

3. Wymagania techniczne dotyczące programu

Wszystkie urzędy certyfikacji w programie muszą być zgodne z wymaganiami technicznymi programu. Jeśli firma Microsoft ustali, że urząd certyfikacji nie jest zgodny z poniższymi wymaganiami, firma Microsoft wykluczy ten urząd certyfikacji z programu.

Odp. Wymagania główne

1. Certyfikaty główne muszą być certyfikatami x.509 w wersji 3.
   1. Atrybut CN musi identyfikować wydawcę i musi być unikatowy.
   2. Atrybut CN musi być w języku, który jest odpowiedni dla rynku urzędu certyfikacji i czytelny przez typowego klienta na tym rynku.
   3. Podstawowe rozszerzenie ograniczeń: musi mieć wartość cA=true.
   4. Rozszerzenie Użycie klucza MUSI być obecne i MUSI być oznaczone jako krytyczne. Należy ustawić pozycje bitowe keyCertSign i cRLSign. Jeśli klucz prywatny głównego urzędu certyfikacji jest używany do podpisywania odpowiedzi OCSP, należy ustawić bit digitalSignature.
      • Rozmiary kluczy głównych muszą spełniać wymagania opisane w sekcji "Wymagania kluczowe".
2. Certyfikaty, które mają zostać dodane do zaufanego magazynu głównego, muszą być certyfikatami głównymi z podpisem własnym.
3. Nowo wybita główna urzędy certyfikacji musi być ważna przez co najmniej osiem lat i maksymalnie 25 lat od daty złożenia.
4. Uczestniczące główne urzędy certyfikacji mogą nie wystawiać nowych certyfikatów RSA 1024-bitowych z katalogów głównych objętych tymi wymaganiami.
5. Wszystkie certyfikaty jednostek końcowych muszą zawierać rozszerzenie AIA z prawidłowym adresem URL dostawcy OCSP. Te certyfikaty mogą również zawierać rozszerzenie CDP, które zawiera prawidłowy adres URL listy CRL. Wszystkie inne typy certyfikatów muszą zawierać rozszerzenie AIA z adresem URL dostawcy OCSP lub rozszerzeniem CDP z prawidłowym adresem URL listy CRL
6. Klucze prywatne i nazwy podmiotów muszą być unikatowe dla certyfikatu głównego; ponowne użycie kluczy prywatnych lub nazw podmiotów w kolejnych certyfikatach głównych przez ten sam urząd certyfikacji może spowodować nieoczekiwane problemy z łańcuchem certyfikatów. Urzędy certyfikacji muszą wygenerować nowy klucz i zastosować nową nazwę podmiotu podczas generowania nowego certyfikatu głównego przed dystrybucją przez firmę Microsoft.
7. Urzędy certyfikacji rządu muszą ograniczyć uwierzytelnianie serwerów do domen najwyższego poziomu wystawionych przez instytucje rządowe i mogą wystawiać tylko inne certyfikaty do ISO3166 kodów kraju, nad którymi kraj ma suwerenną kontrolę (patrz https://aka.ms/auditreqs sekcja III definicji "Urzędu certyfikacji dla instytucji rządowych"). Te wydane przez rząd TLD są określane w poszczególnych urzędach certyfikacji odpowiednich umów.
8. Wystawianie certyfikatów urzędu certyfikacji łączących się z uczestniczącym głównym urzędem certyfikacji musi oddzielić uwierzytelnianie serwera, protokół S/MIME, podpisywanie kodu i użycie sygnatury czasowej. Oznacza to, że pojedynczy urząd wystawiający certyfikaty nie może łączyć uwierzytelniania serwera z protokołem S/MIME, podpisywaniem kodu ani sygnaturą czasową EKU. Dla każdego przypadku użycia należy użyć oddzielnego pośredniego.
9. Certyfikaty jednostek końcowych muszą spełniać wymagania dotyczące typu algorytmu i rozmiaru klucza dla certyfikatów subskrybentów wymienionych w dodatku A wymagań odniesienia forum CAB znajdujących się w https://cabforum.org/baseline-requirements-documents/lokalizacji .
10. Urzędy certyfikacji muszą zadeklarować jeden z następujących identyfikatorów OID zasad w certyfikacie jednostki końcowej rozszerzenia zasad certyfikatu.
    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. Podpisywanie kodu 2.23.140.1.4.1.
11. Od sierpnia 2024 r. wszystkie niestandardowe identyfikatory OID SSL EV zarządzane przez zaufany program główny i odpowiednie narzędzia zostaną usunięte i zastąpione zgodnym z urzędem certyfikacji/B Forum EV SSL OID (2.23.140.1.1). Zespół przeglądarki Microsoft Edge zaimplementuje kontrole identyfikatora OID PROTOKOŁU SSL EV (2.23.140.1.1) w przeglądarce, więc inne identyfikatory oid SSL EV nie będą już akceptowane w celu dopasowania do przeglądarki Edge i uniknięcia niezgodności.
12. Urzędy certyfikacji mogą nie mieć więcej niż 2 identyfikatory operacyjnego zastosowane do certyfikatu głównego.
13. Certyfikaty jednostek końcowych, które zawierają rozszerzenie podstawowe ograniczenia zgodnie z IETF RFC 5280, muszą mieć pole cA ustawione na FALSE, a pole pathLenConstraint musi być nieobecne.
14. Urząd certyfikacji musi technicznie ograniczyć obiekt odpowiadający OCSP, tak aby jedynym dozwolonym kluczem EKU było podpisywanie OCSP.
15. Urząd certyfikacji musi mieć możliwość odwołania certyfikatu do określonej daty zgodnie z żądaniem firmy Microsoft.

B. Wymagania dotyczące podpisu

Algorytm	Wszystkie zastosowania z wyjątkiem podpisywania kodu i sygnatury czasowej	Używanie podpisywania kodu i sygnatur czasowych
Algorytmy szyfrowane	SHA2 (SHA256, SHA384, SHA512)	SHA2 (SHA256, SHA384, SHA512)
RSA	2048	4096 (Tylko nowe korzenie)
ECC / ECDSA	NIST P-256, P-384, P-521	NIST P-256, P-384, P-521

Uwaga: Podpisy korzystające z kryptografii krzywej wielokropka (ECC), takiej jak ECDSA, nie są obsługiwane w systemach Windows i nowszych funkcjach zabezpieczeń systemu Windows. Użytkownicy korzystający z tych algorytmów i certyfikatów będą napotykać różne błędy i potencjalne zagrożenia bezpieczeństwa. Zaufany program główny firmy Microsoft zaleca, aby certyfikaty ECC/ECDSA nie powinny być wystawiane subskrybentom ze względu na tę znaną niezgodność i ryzyko.

C. Wymagania dotyczące odwołania

1. Urzędy certyfikacji muszą mieć udokumentowane zasady odwołania i muszą mieć możliwość odwołania wszelkich wystawianych certyfikatów.
2. Urzędy certyfikacji wystawiające certyfikaty uwierzytelniania serwera muszą obsługiwać oba następujące wymagania dotyczące dostawcy OCSP:
   1. Minimalna ważność ośmiu (8) godzin; maksymalna ważność wynosząca siedem (7) dni.
   2. Następna aktualizacja musi być dostępna co najmniej osiem (8) godzin przed wygaśnięciem bieżącego okresu. Jeśli ważność jest większa niż 16 godzin, następna aktualizacja musi być dostępna o godzinie 1/2 okresu ważności.
3. Wszystkie certyfikaty wystawione przez główny urząd certyfikacji muszą obsługiwać rozszerzenie punktu dystrybucji listy CRL i/lub AIA zawierające adres URL odpowiedzi OCSP.
4. Urząd certyfikacji nie może używać certyfikatu głównego do wystawiania certyfikatów jednostek końcowych.
5. Jeśli urząd certyfikacji wystawia certyfikaty podpisywania kodu, musi użyć urzędu sygnatury czasowej zgodnej z dokumentem RFC 3161" "Internet X.509 Public Key Infrastructure Time-Stamp Protocol(TSP).

D. Wymagania dotyczące certyfikatu głównego podpisywania kodu

1. Certyfikaty główne obsługujące używanie podpisywania kodu mogą zostać usunięte z dystrybucji przez program 10 lat od daty dystrybucji zastępczego certyfikatu głównego przerzucania lub wcześniej, jeśli jest to wymagane przez urząd certyfikacji.
2. Certyfikaty główne, które pozostają w dystrybucji w celu obsługi tylko używania podpisywania kodu poza okresem istnienia zabezpieczeń algorytmu (np. RSA 1024 = 2014, RSA 2048 = 2030) mogą być ustawione na wartość "wyłącz" w systemie operacyjnym Windows 10.
3. Od lutego 2024 r. firma Microsoft nie będzie już akceptować ani rozpoznawać certyfikatów podpisywania kodu EV, a CCADB przestanie akceptować inspekcje podpisywania kodu EV. Począwszy od sierpnia 2024 r., wszystkie identyfikatory operacyjnego podpisywania kodu EV zostaną usunięte z istniejących katalogów głównych programu Microsoft Trusted Root Program, a wszystkie certyfikaty podpisywania kodu będą traktowane w równym stopniu.

E. Wymagania dotyczące EKU

1. Urzędy certyfikacji muszą podać uzasadnienie biznesowe dla wszystkich jednostek EKU przypisanych do ich certyfikatu głównego. Uzasadnienie może być w formie publicznych dowodów bieżącej działalności wystawiającej certyfikaty typu lub typów lub plan biznesowy pokazujący zamiar wystawienia tych certyfikatów w najbliższej perspektywie (w ciągu jednego roku dystrybucji certyfikatów głównych przez program).

2. Firma Microsoft włączy tylko następujące EKU:

   1. Uwierzytelnianie serwera =1.3.6.1.5.5.7.3.1
   2. Uwierzytelnianie klienta =1.3.6.1.5.5.7.3.2
   3. Bezpieczna poczta e-mail EKU=1.3.6.1.5.5.7.3.4
   4. Sygnatura czasowa EKU=1.3.6.1.5.5.7.3.8
   5. Podpisywanie dokumentu EKU=1.3.6.1.4.1.311.10.3.12
   • Ten EKU jest używany do podpisywania dokumentów w pakiecie Office. Nie jest to wymagane w przypadku innych zastosowań podpisywania dokumentów.

F. Wymagania dotyczące podpisywania kodu trybu jądra systemu Windows 10 (KMCS)

System Windows 10 ma zwiększone wymagania dotyczące sprawdzania poprawności sterowników trybu jądra. Sterowniki muszą być podpisane zarówno przez firmę Microsoft, jak i partnera programu przy użyciu rozszerzonych wymagań dotyczących walidacji. Wszyscy deweloperzy, którzy chcą mieć sterowniki trybu jądra zawarte w systemie Windows, muszą postępować zgodnie z procedurami opisanymi przez zespół deweloperów sprzętu firmy Microsoft. Aby uzyskać więcej informacji, zobacz Centrum partnerskie dla sprzętu systemu Windows.