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

1. Wprowadzenie

Główny program certyfikacji firmy Microsoft obsługuje dystrybucję certyfikatów głównych, umożliwiając klientom ufanie Windows produktom. Na tej stronie opisano ogólne i techniczne wymagania programu.

Uwaga

2. Dalsze wymagania dotyczące programu

Wymagania inspekcji

  1. Uczestnicy programu muszą przed przeprowadzaniem operacji komercyjnych, a następnie co rok, przedstawić firmie Microsoft dowód kwalifikowanej inspekcji ( https://aka.ms/auditreqszobacz) dla każdego głównego, niewyszkolonego urzędu certyfikacji podrzędnego i certyfikatu podpisanego krzyżowo.
  2. Uczestnicy programu muszą ponosić odpowiedzialność za zapewnienie, że wszystkie nieprzeszkolone podrzędne umowy certyfikacji i certyfikaty podpisane krzyżowo spełniają wymagania dotyczące inspekcji programu.
  3. W przypadku niezaszkodkowanych podrzędnych jednostek CAs muszą publicznie ujawniać wszystkie raporty inspekcji.

Wymagania dotyczące komunikacji i ujawniania informacji

  1. Uczestnicy programu muszą podać tożsamości co najmniej dwóch "zaufanych agentów" firmy Microsoft, aby pełnić funkcję przedstawicieli programu i jednego ogólnego aliasu e-mail. Uczestnicy programu muszą poinformować firmę Microsoft o usunięciu lub dodatku personelu jako zaufanego agenta. Uczestnicy programu zgadzają się na otrzymywanie informacji pocztą e-mail i muszą podać firmie Microsoft adres e-mail, aby otrzymać oficjalne powiadomienia. Uczestnicy programu muszą zaakceptować, że powiadomienie obowiązuje w przypadku, gdy firma Microsoft wyśle wiadomość e-mail lub oficjalny list. Co najmniej jeden z podanych kontaktów lub aliasów powinien być kanałem komunikacji monitorowanym przez 7 dni w tygodniu w przypadku wniosków o odwołanie lub innych sytuacji zarządzania zdarzeniami.

  2. Uczestnik programu musi co roku ujawniać firmie Microsoft pełną hierarchię licencji PKI (niepowiązany podrzędny urząd certyfikacji, niezarejestrowane główne programy certyfikacji bez podpisów krzyżowych, podrzędne jednostki CA, jednostki EKUS, ograniczenia certyfikatów) firmie Microsoft, w tym certyfikaty wystawiane w ramach usługi CAs obsługiwanych przez zewnętrzne firmy w ramach usługi CCADB. Uczestnicy programu muszą zapewnić dokładność tych informacji w ccADB w przypadku wystąpienia zmian. Jeśli podrzędny urząd certyfikacji nie jest publicznie ujawniany ani poddany inspekcji, musi on być ograniczony domeną.

  3. Uczestnicy programu muszą powiadomić firmę Microsoft za pośrednictwem poczty e-mail co najmniej 120 dni przed przeniesieniem własności zarejestrowanego głównego lub podrzędnego urzędu certyfikacji, który jest łańcuchem do zarejestrowanego katalogu głównego do innej jednostki lub innej osoby.

  4. Kod przyczyny musi być uwzględniony w odwołaniach certyfikatów pośrednich. W przypadku odwoływania certyfikatów pośrednich w ciągu 30 dni usługi CAs muszą zaktualizować bibliotekę CCADB.

  5. Uczestnicy programu są zgodni, że firma Microsoft może kontaktować się z klientami, którzy uważa, że oczekuje na usunięcie głównego urzędu certyfikacji z programu.

Inne wymagania

  1. Komercyjne centrum certyfikacji nie może zarejestrować głównego urzędu certyfikacji w Programie, który ma być przede wszystkim zaufany wewnątrz organizacji (czyli w innych Enterprise certyfikacji).

  2. Jeśli urząd certyfikacji korzysta z podwykonawcy w celu obsługi dowolnego aspektu swojej działalności, urząd certyfikacji przejmie odpowiedzialność za działalność tego podwykonawcy.

  3. Jeśli firma Microsoft według własnego uznania identyfikuje certyfikat, którego użycie lub atrybuty są określone jako niezgodne z celami zaufanego programu głównego, firma Microsoft powiadomi odpowiedzialny urząd certyfikacji i zażąda, aby odwołał certyfikat. Urząd certyfikacji musi odwołać certyfikat lub zażądać wyjątku od firmy Microsoft w ciągu 24 godzin od otrzymania powiadomienia od firmy Microsoft. Firma Microsoft wedle własnego uznania przegląda przesłane materiały i informuje urząd certyfikacji o ostatecznej decyzji o przyznaniu lub odmnieniu wyjątku. Jeśli firma Microsoft nie przyzna wyjątku, urząd certyfikacji musi odwołać certyfikat w ciągu 24 godzin od odrzuconego wyjątku.


3. Wymagania techniczne programu

Wszystkie programy ca w programie muszą być zgodne z wymaganiami technicznymi programu. Jeśli firma Microsoft określi, że urząd certyfikacji nie jest zgodny z poniższymi wymaganiami, firma Microsoft wyklucza ten urząd certyfikacji z programu.

A. 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 urzędu certyfikacji i czytelny dla typowego klienta na tym rynku.
    3. Rozszerzenie ograniczenia podstawowego: musi mieć wartość cA=true.
    4. Rozszerzenie klucza MUSI być obecne i MUSI być oznaczone jako krytyczne. Należy ustawić pozycje Bit dla klucza KeyCertSign i cRLSign. Jeśli do podpisywania odpowiedzi ocSP jest używany klucz prywatny głównego urzędu certyfikacji, należy ustawić bit digitalSignature.
      • Rozmiary kluczy głównych muszą spełniać wymagania opisane w "Wymagania dotyczące kluczy".
  2. Certyfikaty dodawane do zaufanego magazynu głównego MUSZĄ być certyfikatami głównymi z podpisem własnym.
  3. Nowo utworzone główne umowy o wydajności muszą być ważne przez co najmniej 8 lat (maksymalnie 25 lat) od daty przesłania.
  4. Uczestniczące w nim certyfikaty główne mogą nie wydawać nowych 1024-bitowych certyfikatów RSA z katalogów głównych objętych tymi wymaganiami.
  5. Wszystkie certyfikaty jednostki końcowej muszą zawierać rozszerzenie AIA z prawidłowym adresem URL 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 OCSP lub rozszerzeniem CDP z prawidłowym adresem URL listy CRL.
  6. Klucze prywatne i nazwy podmiotów muszą być unikatowe dla każdego certyfikatu głównego. ponowne używanie kluczy prywatnych lub nazw obiektów w kolejnych certyfikatach głównych przez ten sam urząd certyfikacji może powodować nieoczekiwane problemy z łańcuchem certyfikatów. Usługi certyfikacji muszą wygenerować nowy klucz i zastosować nową nazwę podmiotu podczas generowania nowego certyfikatu głównego przed dystrybucją przez firmę Microsoft.
  7. Administracja administracji państwowej musi ograniczyć uwierzytelnianie serwera do domen najwyższego poziomu wydanych przez urząd administracji państwowej i może wydawać tylko inne certyfikaty zgodnie z kodami krajów ISO3166, nad które kraj ma kontrolę suwerenną ( https://aka.ms/auditreqs zobacz sekcję III, aby uzyskać definicję "rządowy urząd certyfikacji"). Te wydany przez urząd administracji państwowej umowy o czas wygaśnięcia są określane w umowie każdego urzędu certyfikacji.
  8. W celu wydania certyfikatów certyfikacji, które są w łańcuchu do głównego urzędu certyfikacji uczestniczącego w programie, należy rozdzielić uwierzytelnianie serwera, S/MIME, podpisywanie kodu i użycie sygnatur czasowych. Oznacza to, że pojedynczy urząd certyfikacji nie może łączyć uwierzytelniania serwera z usługą S/MIME, podpisywaniem kodu lub sygnaturą czasową EKU. Dla każdego przypadku użycia należy użyć oddzielnej wartości pośredniej.
  9. Certyfikaty typu end-entity muszą spełniać wymagania dotyczące typu algorytmu i rozmiaru klucza dla certyfikatów subskrybentów wymienionych w dodatku A forum CAB — wymagania bazowe, które znajdują się w .https://cabforum.org/baseline-requirements-documents/
  10. Firma CA musi zadeklarować jeden z następujących identyfikatorów zasad w swoim 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 EV 2.23.140.1.3
    6. Podpisywanie kodu bez WW 2.23.140.1.4.1
  11. Certyfikaty jednostek końcowych, które zawierają rozszerzenie Podstawowe ograniczenia zgodnie z dokumentem IETF RFC 5280, muszą mieć ustawioną wartość FAŁSZ, a pole pathLenConstraint musi być nieobecne.
  12. Urząd certyfikacji musi technicznie ograniczyć element odpowiadający programowi OCSP, tak aby jedyną dozwoloną usługą EKU było podpisywanie OCSP.
  13. Urząd certyfikacji musi mieć możliwość odwoływania certyfikatu na określoną datę zgodnie z żądaniem firmy Microsoft.

B. Wymagania dotyczące podpisu

Algorytm Wszystkie zastosowania z wyjątkiem podpisywania kodu i sygnatury czasowej Podpisywanie kodu i używanie sygnatury czasowej
Algorytmy podsumowanie SHA2 (SHA256, SHA384, SHA512) SHA2 (SHA256, SHA384, SHA512)
RSA 2048 4096 (tylko nowe katalogi główne)
ECC / ECDSA NIST P-256, P-384, P-521 NIST P-256, P-384, P-521

C. Wymagania dotyczące odwołania

  1. Urząd certyfikacji musi mieć udokumentowane zasady odwołań i musi mieć możliwość odwoływania wszelkich problemów z certyfikatem.
  2. Usługi CA, które wydaje certyfikaty uwierzytelniania serwera, muszą obsługiwać następujące wymagania programu OCSP dla osób odpowiadających:
    1. Minimalna ważność: osiem (8) godzin; Okres ważności: siedem (7) dni; i
    2. Następna aktualizacja musi być dostępna co najmniej osiem (8) godzin przed wygaśnięciem bieżącego okresu. Jeśli okres ważności jest dłuższy niż 16 godzin, następna aktualizacja jest dostępna po 1/2 okresu ważności.
  3. Wszystkie certyfikaty wystawione z głównego urzędu certyfikacji muszą obsługiwać rozszerzenie punktu dystrybucyjnego list CRL i/lub AIA zawierające adres URL osoby odpowiadającej programowi OCSP.
  4. Urząd certyfikacji nie może używać certyfikatu głównego do wydawania certyfikatów jednostek końcowych.
  5. Jeśli urząd certyfikacji wydaje certyfikaty podpisywania kodu, musi użyć urzędu sygnatury czasowej zgodnego z protokołem RFC 3161, "Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)".

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

  1. Certyfikaty główne, które obsługują używanie podpisywania kodu, mogą zostać usunięte z dystrybucji przez Program po 10 latach od daty wydania zastępczego certyfikatu głównego wycofywania lub szybciej, jeśli zażąda tego urząd certyfikacji.
  2. Certyfikaty główne, które pozostają w dystrybucji w celu obsługi tylko używania kodu podpisywania poza okresem istnienia zabezpieczeń algorytmu (np. RSA 1024 = 2014, RSA 2048 = 2030) mogą być ustawione na "wyłączone" w Windows 10 OS.

E. Wymagania dotyczące EKU

  1. W przypadku wszystkich EKU przypisanych do ich certyfikatów głównych w usługach certyfikacji muszą być one uzasadnienia biznesowego. Uzasadnienie może być dowodem publicznym dowodu bieżącej firmy w związku z wydaniem certyfikatów tego typu lub planu biznesowego wskazującego na zamiar wydawania tych certyfikatów w najbliższym czasie (w ciągu roku od wydania certyfikatu głównego 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. Secure 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. Podpis dokumentów EKU=1.3.6.1.4.1.311.10.3.12
    • Ta EKU jest używana do podpisywania dokumentów w ramach Office. Nie jest on wymagany w innych zastosowaniach podpisywania dokumentów.

F. Windows 10 kodów w trybie kernelu (KMCS, Kernel Mode Code Signing)

Windows 10 wymagania dotyczące sprawdzania poprawności sterowników trybów kernelu. Sterowniki muszą być podpisane przez firmę Microsoft i partnera programu przy użyciu wymagań rozszerzonej weryfikacji. Wszyscy deweloperzy, którzy chcą mieć sterowniki trybów kernelu zawarte w programie Windows muszą wykonać procedury opisane przez Zespół deweloperów sprzętu firmy Microsoft. Dokumentację programu można znaleźć tutaj