Udostępnij za pośrednictwem

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

2. Dalsze wymagania dotyczące programu

Wymagania dotyczące inspekcji

  1. Uczestnicy programu muszą dostarczyć firmie Microsoft dowody na inspekcję kwalifikującą (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 audytu dla nieograniczonych podrzędnych urzędów certyfikacji.
  4. Dostawcy urzędów certyfikacji muszą zapewnić, że główne urzędy certyfikacji, które obsługują S/MIME, i wszystkie podrzędne urzędy certyfikacji zdolne do wystawiania certyfikatów S/MIME zostały i będą nadal audytowane zgodnie z najnowszą wersją co najmniej 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 WebTrust dla urzędów certyfikacji — S/MIME
    • ETSI EN 119 411-6 LCP, NCP lub NCP+

Wymagania dotyczące komunikacji i ujawniania informacji

  1. Uczestnicy programu muszą podać firmie Microsoft tożsamości co najmniej dwóch "zaufanych agentów", aby reprezentowali program, oraz jeden ogólny alias emailowy. 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ć 24/7 monitorowanym kanałem komunikacji do zgłaszania żądań unieważnienia lub innych sytuacji związanych z zarządzaniem incydentami.

  2. Uczestnik programu musi ujawnić pełną hierarchię PKI (nielimitowany podrzędny urząd certyfikacji, główne urzędy certyfikacji z podpisem krzyżowym, które nie są zapisane, podrzędne urzędy certyfikacji, EKU, ograniczenia certyfikatów) firmie Microsoft corocznie, w tym certyfikaty wystawione dla urzędów certyfikacji obsługiwanych przez obce podmioty trzecie w 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 audytowany, musi być ograniczony do konkretnej domeny.

  3. Uczestnicy programu muszą poinformować firmę Microsoft pocztą e-mail co najmniej 120 dni przed przeniesieniem własności zarejestrowanego urzędu certyfikacji głównego lub podrzędnego, który jest powiązany z zarejestrowanym głównym urzędem certyfikacji, do innej jednostki lub osoby.

  4. Kod przyczyny musi być uwzględniony w odwołaniach dla certyfikatów pośrednich. Urzędy certyfikacji muszą zaktualizować CCADB przy odwoływaniu wszystkich certyfikatów pośrednich w ciągu 30 dni.

  5. Uczestnicy programu zgadzają się, że firma Microsoft może skontaktować się z klientami, którzy mogą zostać istotnie dotknięci planowanym usunięciem głównej jednostki certyfikującej z programu.

Inne wymagania

  1. 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).

  2. 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.

  3. 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 uczestniczące 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 odpowiednim dla rynku CA i czytelny dla przeciętnego 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. Pozycje bitowe dla keyCertSign i cRLSign muszą być ustawione. 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 poniżej w sekcji "Wymagania dotyczące podpisu".
  2. Certyfikaty, które mają zostać dodane do zaufanego magazynu głównego, muszą być certyfikatami głównymi z podpisem własnym.
  3. Nowo wyemitowany Urząd Certyfikacji Główny musi być ważny przez co najmniej osiem lat i maksymalnie 25 lat od dnia złożenia wniosku.
  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 wystawiane przez urząd certyfikacji muszą zawierać rozszerzenie CDP zawierające prawidłowy CRL i/lub rozszerzenie AIA do obiektu odpowiadającego OCSP. Certyfikat jednostki końcowej może zawierać rozszerzenie AIA z prawidłowym adresem URL OCSP i/lub rozszerzenie CDP wskazujące prawidłowy punkt końcowy HTTP zawierający Listę Odwołania Certyfikatów (CRL). Jeśli rozszerzenie AIA z poprawnym adresem URL OCSP nie jest dołączone, wynikowy plik CRL powinien wynosić <10 MB.
  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ą wymienione w odpowiednich umowach każdego urzędu certyfikacji.
  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 elementu pośredniczącego.
  9. Certyfikaty końcowe muszą spełniać wymagania dotyczące typu algorytmu i rozmiaru klucza dla certyfikatów subskrybentów wymienionych w Dodatku A Podstawowych Wymagań forum CAB zlokalizowanych w https://cabforum.org/baseline-requirements-documents/.
  10. Urzędy certyfikacji muszą zadeklarować jeden z następujących identyfikatorów OID w rozszerzeniu zasad certyfikatu dla certyfikatu jednostki końcowej.
    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. Nie-EV podpisywanie kodu 2.23.140.1.4.1.
    6. S/MIME Legacy zweryfikowana poczta 2.23.140.1.5.1.1.
    7. Skrzynka pocztowa S/MIME zweryfikowała multipurpose 2.23.140.1.5.1.2.
    8. Skrzynka pocztowa S/MIME zweryfikowała wartość Strict 2.23.140.1.5.1.3.
    9. Organizacja S/MIME zweryfikowała starszą 2.23.140.1.5.2.1.
    10. Organizacja S/MIME zweryfikowała wielozadaniowe 2.23.140.1.5.2.2.
    11. Organizacja S/MIME zweryfikowała wartość Strict 2.23.140.1.5.2.3.
    12. Zweryfikowany przez sponsora standard S/MIME typu Legacy 2.23.140.1.5.3.1.
    13. S/MIME Sponsor Validated Multipurpose 2.23.140.1.5.3.2.
    14. Sponsor S/MIME zweryfikował strict 2.23.140.1.5.3.3.
    15. S/MIME Osoba ze zweryfikowanym podpisem w wersji starszej 2.23.140.1.5.4.1.
    16. S/MIME Individual Validated Multipurpose 2.23.140.1.5.4.2.
    17. S/MIME Indywidualne zweryfikowane Strict 2.23.140.1.5.4.3.
  11. Od sierpnia 2024 r. wszystkie niestandardowe identyfikatory OID SSL EV zarządzane przez program Trusted Root oraz nasze odpowiednie narzędzia zostaną usunięte i zastąpione zgodnym z wytycznymi CA/B Forum identyfikatorem OID EV SSL (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 OID 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 certyfikacyjny musi technicznie ograniczyć serwer OCSP tak, aby jedynym dozwolonym rozszerzeniem klucza 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 Nieobsługiwane

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.
  • Podpisywanie kodu nie obsługuje kryptografii krzywych eliptycznych (ECC) ani kluczy > 4096

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. Wymagania dotyczące odpowiedzi OCSP: a. Minimalna ważność ośmiu (8) godzin; Maksymalna ważność wynosząca siedem (7) dni; i b. 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 po upływie połowy okresu ważności.

  3. Zalecenia dotyczące listy CRL, gdy OCSP nie jest dostępny: a. Powinna zawierać rozszerzenie specyficzne dla Microsoftu 1.3.6.1.4.1.311.21.4 (Kolejne opublikowanie CRL). b. Nowa lista CRL powinna być dostępna w następnym czasie publikowania listy CRL. c. Maksymalny rozmiar pliku CRL (pełnego CRL lub partycjonowanego CRL) nie powinien przekraczać 10 MB.

    Uwaga

    Celem sekcji 3.C.3 — zalecenia dotyczące CRL, gdy OCSP nie jest dostępny, jest zapewnienie ochrony użytkownikom końcowym w przypadkach masowego odwołania.

  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 zgodnego z dokumentem "RFC 3161, Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)."

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

  1. Główne certyfikaty obsługujące podpisywanie kodu mogą zostać usunięte z dystrybucji w ramach Programu 10 lat od daty dystrybucji zamiennika certyfikatu głównego z funkcją rollover lub wcześniej, jeśli zażąda tego 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 OID podpisywania kodu EV zostaną usunięte z istniejących korzeni programu Microsoft Trusted Root Program, a wszystkie certyfikaty podpisywania kodu będą traktowane jednakowo.

E. Wymagania dotyczące EKU

  1. Urzędy certyfikacji muszą przedłożyć uzasadnienie biznesowe dla wszystkich EKU przypisanych do ich certyfikatu nadrzędnego. 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 dokumentów EKU=1.3.6.1.4.1.311.10.3.12
    • Ten EKU służy do podpisywania dokumentów w programie 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.

  • Last updated on