Programmanforderungen: Microsoft Trusted Root Program

1. Einführung

Das Microsoft-Stammzertifikatprogramm unterstützt die Verteilung von Stammzertifikaten, sodass Kunden Windows-Produkten vertrauen können. Auf dieser Seite werden die allgemeinen und technischen Anforderungen des Programms beschrieben.

2. Weitere Programmanforderungen

Überwachungsanforderungen

1. Programmteilnehmer müssen Microsoft einen Nachweis einer qualifizierten Überwachung (siehe https://aka.ms/auditreqs) für jedes Stammzertifikat, jede nicht eingeschränkte untergeordnete Zertifizierungsstelle und jedes kreuzsignierte Zertifikat bereitstellen, bevor sie kommerzielle Vorgänge durchführen und anschließend auf jährlicher Basis.
2. Programmteilnehmer müssen die Verantwortung übernehmen, sicherzustellen, dass alle uneingeschränkten untergeordneten Zertifizierungsstellen und kreuzsignierten Zertifikate die Programmüberwachungsanforderungen erfüllen.
3. Zertifizierungsstellen müssen alle Überwachungsberichte für nicht eingeschränkte untergeordnete Zertifizierungsstellen öffentlich offenlegen.
4. ZS-Anbieter müssen sicherstellen, dass ihre mit S/MIME aktivierten Stammzertifizierungsstellen und alle untergeordneten Zertifizierungsstellen, die S/MIME-Zertifikate ausstellen können, mindestens auf die neueste Version überprüft werden oder für die einer der folgenden Kriteriensätze überprüft wird. Diese Überprüfung muss mindestens einmal pro Jahr erfolgen. Eine erste Überprüfung muss spätestens am 1. September 2023 beginnen.
   
   • WebTrust-Prinzipien und -Kriterien für Zertifizierungsstellen – S/MIME
     
   • ETSI EN 119 411-6 LCP, NCP oder NCP und höher
     

Kommunikations- und Offenlegungsanforderungen

4. Programmteilnehmer müssen Microsoft die Identitäten von mindestens zwei „vertrauenswürdigen Agenten“ bereitstellen, die als Vertreter für das Programm fungieren, sowie einen allgemeinen E-Mail-Alias. Programmteilnehmer müssen Microsoft über das Entfernen oder Hinzufügen von Mitarbeitern als vertrauenswürdiger Agent informieren. Programmteilnehmer stimmen dem Empfang von Benachrichtigungen per E-Mail zu und müssen Microsoft eine E-Mail-Adresse angeben, um offizielle Benachrichtigungen zu erhalten. Programmteilnehmer müssen zustimmen, dass der Hinweis wirksam wird, wenn Microsoft eine E-Mail oder ein offizielles Schreiben sendet. Mindestens einer der bereitgestellten Kontakte oder Aliase sollte ein überwachter 24/7-Kommunikationskanal für Rückrufanforderungen oder andere Vorfallsmanagement-Situationen sein.

5. Der Programmteilnehmer muss seine vollständige PKI-Hierarchie (nicht getrennte untergeordnete Zertifizierungsstelle, signierte nicht registrierte Stamm-CAs, untergeordnete CAs, EKUs, Zertifikatbeschränkungen) jährlich an Microsoft weitergeben, einschließlich Der Zertifikate, die von externen Dritten innerhalb der CCADB betrieben werden. Programmteilnehmer müssen diese Informationen in der CCADB exakt speichern, wenn Änderungen auftreten. Wenn eine untergeordnete Zertifizierungsstelle nicht öffentlich offengelegt oder überwacht wird, muss sie domänenbeschränkt sein.

6. Programmteilnehmer müssen Microsoft mindestens 120 Tage zuvor per E-Mail informieren, bevor sie den Besitz einer registrierten Stamm- oder untergeordneten Zertifizierungsstelle, die an einen registrierten Stamm verkettet ist, an eine andere Organisation oder Person übertragen.

7. Der Grundcode muss in Widerrufen für Zwischenzertifikate enthalten sein. Zertifizierungsstellen müssen die CCADB aktualisieren, wenn sie Zwischenzertifikate innerhalb von 30 Tagen widerrufen.

8. Programmteilnehmer erklären sich damit einverstanden, dass Microsoft Kunden kontaktieren darf, von denen Microsoft der Meinung ist, dass die ausstehende Entfernung einer Stammzertifizierungsstelle aus dem Programm erhebliche Auswirkungen haben könnte.

Andere Anforderungen

9. Kommerzielle Zertifizierungsstellen dürfen keine Stammzertifizierungsstelle für das Programm registrieren, das in erster Linie intern innerhalb einer Organisation als vertrauenswürdig eingestuft werden soll (d. h. Unternehmenszertifizierungsstellen).

10. Wenn eine Zertifizierungsstelle einen Vertragsnehmer verwendet, um einen Aspekt ihres Geschäfts zu betreiben, übernimmt die Zertifizierungsstelle die Verantwortung für dessen Geschäftsbetrieb.

11. Wenn Microsoft nach eigenem Ermessen ein Zertifikat identifiziert, dessen Verwendung oder Attribute gegen die Ziele des vertrauenswürdigen Stammprogramms verstößt, benachrichtigt Microsoft die zuständige Zertifizierungsstelle und fordert den Widerruf des Zertifikats an. Die Zertifizierungsstelle muss entweder das Zertifikat widerrufen oder innerhalb von 24 Stunden nach Erhalt der Microsoft-Benachrichtigung eine Ausnahme von Microsoft anfordern. Microsoft überprüft übermittelte Materialien und informiert die Zertifizierungsstelle nach eigenem Ermessen über ihre endgültige Entscheidung, die Ausnahme zu gewähren oder zu verweigern. Wenn Microsoft die Ausnahme nicht gewährt, muss die Zertifizierungsstelle das Zertifikat innerhalb von 24 Stunden nach dem Verweigerten der Ausnahme widerrufen.

3. Technische Anforderungen des Programms

Alle Zertifizierungsstellen im Programm müssen die technischen Anforderungen des Programms erfüllen. Wenn Microsoft feststellt, dass eine Zertifizierungsstelle nicht den unten angegebenen Anforderungen entspricht, schließt Microsoft diese Zertifizierungsstelle aus dem Programm aus.

A. Stammanforderungen

1. Stammzertifikate müssen x.509 v3-Zertifikate sein.
   1. Das CN-Attribut muss den Herausgeber identifizieren und eindeutig sein.
   2. Das CN-Attribut muss in einer Sprache sein, die für den Markt der Zertifizierungsstelle geeignet und für einen typischen Kunden auf diesem Markt lesbar ist.
   3. Basic Constraints-Erweiterung: muss cA=true sein.
   4. Die Schlüsselverwendungserweiterung MUSS vorhanden und als kritisch gekennzeichnet sein. Bitpositionen für KeyCertSign und cRLSign MÜSSEN festgelegt werden. Wenn der private Schlüssel der Stammzertifizierungsstelle zum Signieren von OCSP-Antworten verwendet wird, MUSS das digitalSignature-Bit festgelegt werden.
      • Die Stammschlüsselgrößen müssen die anforderungen erfüllen, die unten unter "Signaturanforderungen" beschrieben sind.
2. Zertifikate, die dem vertrauenswürdigen Stammspeicher hinzugefügt werden sollen, MÜSSEN selbstsigniert sein.
3. Neu erworbene Stammzertifizierungsstellen müssen ab dem Übermittlungsdatum mindestens acht Jahre und maximal 25 Jahre gültig sein.
4. Teilnehmende Stammzertifizierungsstellen stellen möglicherweise keine neuen 1024-Bit-RSA-Zertifikate von Stammzertifizierungsstellen aus, die von diesen Anforderungen abgedeckt werden.
5. Alle ausstellenden Zertifizierungsstellenzertifikate müssen entweder eine CDP-Erweiterung mit einer gültigen CRL und/oder eine AIA-Erweiterung für einen OCSP-Responder enthalten. Ein Endentitätszertifikat kann entweder eine AIA-Erweiterung mit einer gültigen OCSP-URL und/oder eine CDP-Erweiterung enthalten, die auf einen gültigen HTTP-Endpunkt zeigt, der die CRL enthält. Wenn eine AIA-Erweiterung mit einer gültigen OCSP-URL NICHT enthalten ist, sollte die resultierende CRL-Datei 10 MB groß sein <.
6. Private Schlüssel und Antragstellernamen müssen pro Stammzertifikat eindeutig sein. Die Wiederverwendung privater Schlüssel oder Antragstellernamen in nachfolgenden Stammzertifikaten durch dieselbe Zertifizierungsstelle kann zu unerwarteten Problemen bei der Zertifikatverkettung führen. Zertifizierungsstellen müssen einen neuen Schlüssel generieren und beim Generieren eines neuen Stammzertifikats vor der Verteilung durch Microsoft einen neuen Antragstellernamen anwenden.
7. Regierungszertifizierungsstellen müssen die Serverauthentifizierung auf von der Regierung ausgestellte Top-Level-Domains beschränken und dürfen andere Zertifikate nur für die ISO3166-Ländercodes ausstellen, über die das Land die souveräne Kontrolle hat (siehe https://aka.ms/auditreqs Abschnitt III für die Definition einer „Regierungszertifizierungsstelle“). Auf diese behördlich ausgestellten TLDs werden im entsprechenden Vertrag jeder Zertifizierungsstelle verwiesen.
8. Das Ausstellen von Zertifizierungsstellenzertifikaten, die mit einer beteiligten Stammzertifizierungsstelle verkettet sind, muss die Verwendung von Serverauthentifizierung, S/MIME, Codesignatur und Zeitstempel trennen. Dies bedeutet, dass eine einzelne ausstellende Zertifizierungsstelle die Serverauthentifizierung nicht mit S/MIME, Codesignatur oder Zeitstempel-EKU kombinieren darf. Für jeden Verwendungsfall muss ein separater Zwischenschritt verwendet werden.
9. Endorganisationszertifikate müssen die Anforderungen für Algorithmustyp und Schlüsselgröße für Abonnentenzertifikate erfüllen, die in Anhang A des CAB-Forums Basisanforderungen unter https://cabforum.org/baseline-requirements-documents/ aufgeführt sind.
10. Zertifizierungsstellen müssen eine der folgenden Richtlinien-OIDs im Endorganisationszertifikat der Zertifikatrichtlinienerweiterung deklarieren.
    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. Nicht-EV-Codesignierung 2.23.140.1.4.1.
    6. S/MIME-Postfach überprüft Legacy 2.23.140.1.5.1.1.1.
    7. S/MIME Mailbox Validated Multipurpose 2.23.140.1.5.1.2.
    8. S/MIME-Postfach überprüft Strict 2.23.140.1.5.1.3.
    9. S/MIME-Organisation hat Legacy 2.23.140.1.5.2.1 überprüft.
    10. S/MIME-Organisation überprüfte Multipurpose 2.23.140.1.5.2.2.
    11. S/MIME-Organisation überprüft Strict 2.23.140.1.5.2.3.
    12. S/MIME-Sponsor überprüft Legacy 2.23.140.1.5.3.1.
    13. S/MIME-Sponsor validiert multipurpose 2.23.140.1.5.3.2.
    14. S/MIME-Sponsor überprüft Strict 2.23.140.1.5.3.3.
    15. S/MIME Individual Validated Legacy 2.23.140.1.5.4.1.
    16. S/MIME Individual Validated Multipurpose 2.23.140.1.5.4.2.
    17. S/MIME Individual Valid Strict 2.23.140.1.5.4.3.
11. Ab August 2024 werden alle benutzerdefinierten EV SSL-OIDs, die vom Trusted Root Program verwaltet werden, entfernt und durch die mit dem CA/B Forum konforme EV SSL-OID-Nummer (2.23.140.1.1.1) ersetzt. Das Microsoft Edge-Team implementiert Überprüfungen für EV SSL-OID (2.23.140.1.1) im Browser, sodass sich andere EV SSL-OIDs nicht mehr an Edge ausrichten dürfen und um Inkompatibilitäten zu vermeiden.
12. Zertifizierungsstellen dürfen nicht mehr als zwei OIDs auf ihr Stammzertifikat angewendet haben.
13. Für Endentitätszertifikate, die eine Basic Constraints-Erweiterung gemäß IETF RFC 5280 enthalten, muss das cA-Feld auf FALSE festgelegt sein, und das Feld pathLenConstraint muss fehlen.
14. Eine Zertifizierungsstelle muss einen OCSP-Responder technisch so einschränken, dass die einzige zulässige EKU die OCSP-Signatur ist.
15. Eine Zertifizierungsstelle muss in der Lage sein, ein Zertifikat auf ein bestimmtes Datum zu widerrufen, wie von Microsoft angefordert.

B. Signaturanforderungen

Hinweis:

• Signaturen mit Elliptical Curve Cryptography (ECC), z. B. ECDSA, werden in Windows und neueren Windows-Sicherheitsfeatures nicht unterstützt. Bei Benutzern, die diese Algorithmen und Zertifikate verwenden, treten verschiedene Fehler und potenzielle Sicherheitsrisiken auf. Das Microsoft Trusted Root Program empfiehlt, dass ECC/ECDSA-Zertifikate aufgrund dieser bekannten Inkompatibilität und dieses Risikos nicht für Abonnenten ausgestellt werden sollten.
• Bei der Codesignierung werden ECC oder Schlüssel > 4096 nicht unterstützt.

C. Widerrufsanforderungen

1. Die Zertifizierungsstelle muss über eine dokumentierte Sperrrichtlinie verfügen und über die Möglichkeit verfügen, alle ausgestellten Zertifikate zu widerrufen.

2. OCSP-Antworteranforderungen: a. Mindestgültigkeit von acht (8) Stunden; Maximale Gültigkeit von sieben (7) Tagen; und b. Das nächste Update muss mindestens acht (8) Stunden vor Ablauf des aktuellen Zeitraums verfügbar sein. Wenn die Gültigkeit mehr als 16 Stunden beträgt, muss das nächste Update am 1/2 der Gültigkeitszeitraum verfügbar sein.

3. CRL-Empfehlungen, wenn OCSP nicht vorhanden ist: a. Sollte microsoftspezifische Erweiterung 1.3.6.1.4.1.311.21.4 (Nächste CRL-Veröffentlichung) enthalten. b. Neue CRL sollte zur Nächsten CRL-Veröffentlichungszeit verfügbar sein. c. Die maximale Größe der CRL-Datei (entweder vollständige CRL oder partitionierte CRL) darf 10M nicht überschreiten.

   Hinweis

   Ziel von Abschnitt 3.C.3- CRL-Empfehlungen, wenn OCSP nicht vorhanden ist, besteht darin, Endbenutzern in Fällen des Massensperrens Abdeckung zu bieten.

4. Die Zertifizierungsstelle darf das Stammzertifikat nicht zum Ausstellen von Endentitätszertifikaten verwenden.

5. Wenn eine Zertifizierungsstelle Codesignaturzertifikate ausstellt, muss sie eine Zeitstempelautorität verwenden, die RFC 3161,„Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)“ entspricht.

D: Anforderungen an das Codesigning für Stammzertifikate

1. Stammzertifikate, welche die Codesignaturverwendung unterstützen, können vom Programm 10 Jahre nach dem Verteilungsdatum eines Ersatzrollover-Stammzertifikats oder früher aus der Verteilung entfernt werden, falls dies von der Zertifizierungsstelle angefordert wird.
2. Stammzertifikate, die weiterhin verteilt werden, um nur die Codesignatur zu unterstützen, die über die Lebensdauer der Algorithmussicherheit hinausgehen (z. B. RSA 1024 = 2014, RSA 2048 = 2030), können im Windows 10 Betriebssystem auf „disable“ festgelegt werden.
3. Ab Februar 2024 akzeptiert oder erkennt Microsoft keine EV-Codesignaturzertifikate mehr an, und CCADB akzeptiert keine EV-Codesignaturprüfungen mehr. Ab August 2024 werden alle EV-Codesignatur-OIDs aus vorhandenen Stämmen im Microsoft Trusted Root Program entfernt, und alle Codesignaturzertifikate werden gleichermaßen behandelt.

E. EKU-Anforderungen

1. Zertifizierungsstellen müssen eine geschäftliche Begründung für alle EKUs angeben, die ihrem Stammzertifikat zugewiesen sind. Die Begründung kann in Form eines öffentlichen Beweises für ein aktuelles Geschäft der Ausstellung von Zertifikaten eines Typs oder Typen oder eines Geschäftsplans sein, der die Absicht zeigt, diese Zertifikate in naher Zukunft ausstellen zu wollen (innerhalb eines Jahres nach der Verteilung des Stammzertifikats durch das Programm).

2. Microsoft wird nur die folgenden EKUs aktivieren:

   1. Serverauthentifizierung =1.3.6.1.5.5.7.3.1
   2. Clientauthentifizierung =1.3.6.1.5.5.7.3.2
   3. Sichere E-Mail-EKU=1.3.6.1.5.5.7.3.4
   4. Zeitstempel-EKU=1.3.6.1.5.5.7.3.8
   5. Dokumentsignierung-EKU=1.3.6.1.4.1.311.10.3.12
   • Diese EKU wird zum Signieren von Dokumenten in Office verwendet. Dies ist für andere Dokumentsignaturen nicht erforderlich.

F. Windows 10 Kernelmodus-Codesignatur (KMCS) Anforderungen

Windows 10 hat die Anforderungen an die Überprüfung von Kernelmodustreibern angehoben. Treiber müssen sowohl von Microsoft als auch von einem Programmpartner mit erweiterten Validierungsanforderungen signiert werden. Alle Entwickler, die ihre Kernelmodustreiber in Windows enthalten möchten, müssen die vom Microsoft-Hardwareentwicklungsteam beschriebenen Verfahren befolgen. Weitere Informationen finden Sie im Partner Center für Windows-Hardware.