RFC-Compliance

Certificate Authority Service nutzt das ZLint-Tool, um sicherzustellen, dass X.509-Zertifikate gemäß RFC 5280-Regeln gültig sind. CA Service erzwingt jedoch nicht alle RFC 5280-Anforderungen und es ist möglich, dass eine Zertifizierungsstelle, die mit CA Service erstellt wurde, ein nicht konformes Zertifikat ausstellt.

CA Service erzwingt die folgenden RFC 5280-Anforderungen.

RFC 5280-Abschnitt	Lint-Klausel
4.1.1.2	signatureAlgorithm im Zertifikat MUSS dieselbe Algorithmus-ID enthalten wie das Signaturfeld in der Sequenz „tbsCertificate“ (Abschnitt 4.1.2.3).
4.1.2.1	Wenn Erweiterungen verwendet werden, wie in diesem Profil erwartet, MUSS die Version 3 sein (Wert ist 2).
4.1.2.2	Die Seriennummer MUSS eine positive Ganzzahl sein, die von der Zertifizierungsstelle jedem Zertifikat zugewiesen wird.
4.1.2.2	Übereinstimmende Zertifizierungsstellen DÜRFEN KEINE seriellen Werte verwenden, die länger als 20 Oktette sind.
4.1.2.4	Das Ausstellerfeld MUSS einen nicht leeren Distinguished Name (DN) enthalten.
4.1.2.5	Zertifizierungsstellen, die diesem Profil entsprechen, MÜSSEN die Gültigkeit des Zertifikats bis ins Jahr 2049 immer als UTCTime codieren.
4.1.2.5.1	UTCTime-Werte MÜSSEN in Greenwich Mean Time (Zulu) ausgedrückt werden.
4.1.2.5.1	UTCTime-Werte MÜSSEN Sekunden enthalten.
4.1.2.5.2	GeneralizedTime-Werte MÜSSEN in Greenwich Mean Time (Zulu) ausgedrückt werden.
4.1.2.5.2	GeneralizedTime MUSS Sekunden enthalten
4.1.2.5.2	GeneralizedTime-Werte DÜRFEN KEINE Sekundenbruchteile enthalten
4.1.2.6	Wenn das Subjekt eine Zertifizierungsstelle ist (z.B. die Erweiterung für grundlegende Einschränkungen, wie in Abschnitt 4.2.1.9 beschrieben, vorhanden ist und der Wert von cA TRUE ist), MUSS das Feld für die Betreffzeile mit einem nicht leeren Distinguished Name gefüllt werden, der dem Inhalt des Ausstellerfelds (Abschnitt 4.1.2.4) in allen Zertifikaten entspricht, die von der betreffenden Zertifizierungsstelle ausgestellt wurden.
4.1.2.8	Felder zur eindeutigen Kennzeichnung DÜRFEN nur angezeigt werden, wenn Version 2 oder 3 lautet.
4.1.2.8	CAs, die diesem Profil entsprechen, dürfen KEINE Zertifikate mit eindeutigen Kennungen generieren.
4.1.2.9	Das Feld für Erweiterungen DARF nur bei Version 3 angezeigt werden.
4.2	Ein Zertifikat DARF NICHT mehr als eine Instanz einer bestimmten Erweiterung enthalten.
4.2	Wenn die Zertifizierungsstelle Zertifikate mit einer leeren Sequenz für das Feld „Betreff“ ausstellt, MUSS die Zertifizierungsstelle die alternative Namenserweiterung für den Antragsteller unterstützen.
4.2.1.1	Das Feld „keyIdentifier“ der Erweiterung „authorKeyIdentifier“ MUSS in allen Zertifikaten enthalten sein, die von konformen Zertifizierungsstellen generiert werden, um den Aufbau des Zertifizierungspfads zu erleichtern.
4.2.1.1	Konforme Zertifizierungsstellen MÜSSEN die Erweiterung „authorKeyIdentifier“ als nicht kritisch kennzeichnen.
4.2.1.2	Um den Zertifizierungspfad zu erleichtern, MUSS „authorKeyIdentifier“ in allen konformen CA-Zertifikaten angezeigt werden, d. h. in allen Zertifikaten, einschließlich der Erweiterung „Basic Restrictions“ (Abschnitt 4.2.1.9), bei denen der Wert von cA TRUE ist.
4.2.1.2	konforme Zertifizierungsstellen MÜSSEN die Erweiterung der Schlüsselkennung für den Sachverhalt als nicht kritisch kennzeichnen.
4.2.1.3	Wenn das keyCertSign-Bit bestätigt wird, MUSS auch das cA-Bit in der Erweiterung „Basic Restrictions“ (Abschnitt 4.2.1.9) geltend gemacht werden.
4.2.1.3	Wenn die keyUsage-Erweiterung in einem Zertifikat erscheint, MUSS mindestens eines der Bits auf 1 gesetzt sein.
4.2.1.4	Die OID einer Zertifikatsrichtlinie DARF NICHT mehrmals in einer Erweiterung für Zertifikatsrichtlinien vorkommen.
4.2.1.4	Wenn Qualifier mit der speziellen Richtlinie „anyPolicy“ verwendet werden, MÜSSEN sie auf die in diesem Abschnitt angegebenen Qualifier beschränkt sein.
4.2.1.5	Richtlinien DÜRFEN NICHT dem oder dem speziellen Wert „anyPolicy“ zugeordnet werden
4.2.1.6	Wenn solche Identitäten (irgendetwas in einem SAN) an ein Zertifikat gebunden werden sollen, MUSS der alternative Antragstellername (oder der alternative Ausstellername) verwendet werden.
4.2.1.6	Wenn das Feld „subject“ eine leere Sequenz enthält, MUSS die ausstellende Zertifizierungsstelle die Erweiterung „subjectAltName“ enthalten, die als kritisch gekennzeichnet ist.
4.2.1.6	Wenn die Erweiterung subjectAltName eine Internet-E-Mail-Adresse enthält, MUSS diese Adresse im rfc822Name gespeichert sein.
4.2.1.6	Bei IP-Version 4 MUSS die Oktettzeichenfolge wie in [RFC 791] angegeben genau vier Oktette enthalten. Bei IP-Version 6 MUSS die Oktettzeichenfolge wie in [RFC 2460] angegeben genau sechzehn Oktette enthalten.
4.2.1.6	Wenn die Erweiterung subjectAltName ein Label für das Domain Name System enthält, MUSS der Domainname im dNSName (ein IA5String) gespeichert werden.
4.2.1.6	SANs: Der dNSName MUSS die bevorzugte Namenssyntax aufweisen.
4.2.1.6	subjectAltName-Erweiterungen mit dem dNSName " " DÜRFEN NICHT verwendet werden.
4.2.1.6	Die Verwendung der DNS-Darstellung für Internet-E-Mail-Adressen (Abonnent.beispiel.de anstelle von [e-mail]) DARF NICHT verwendet werden.
4.2.1.6	Wenn die Erweiterung subjectAltName einen URI enthält, MUSS der Name im uniformResourceIdentifier (ein IA5String) gespeichert werden.
4.2.1.6	SAN-URIs: Der Name DARF KEIN relativer URI sein und MUSS der in [RFC 3986] festgelegten Syntax und Codierungsregeln für URIs entsprechen.
4.2.1.6	SAN-URIs: Der Name MUSS sowohl ein Schema (z.B. „http“ oder „ftp“) und einen schemaspezifischen Teil enthält.
4.2.1.6	SAN-URIs mit einer Zertifizierungsstelle ([RFC 3986], Abschnitt 3.2) MÜSSEN einen voll qualifizierten Domainnamen oder eine IP-Adresse als Host enthalten.
4.2.1.6	Wenn die Erweiterung subjectAltName vorhanden ist, MUSS die Sequenz mindestens einen Eintrag enthalten.
4.2.1.6	konforme Zertifizierungsstellen dürfen KEINE Zertifikate für subjectAltNames ausstellen, die leere GeneralName-Felder enthalten.
4.2.1.7	Der alternative Name des Ausstellers MUSS wie in 4.2.1.6 codiert sein.
4.2.1.8	Subject Directory-Attribute: konforme Zertifizierungsstellen MÜSSEN diese Erweiterung als nicht kritisch kennzeichnen.
4.2.1.9	Das Feld „pathLenConstraint“ MUSS größer oder gleich null sein.
4.2.1.9	konforme CAs MÜSSEN diese Erweiterung in alle CA-Zertifikate mit öffentlichen Schlüsseln aufnehmen, die zur Validierung digitaler Signaturen in Zertifikaten verwendet werden, und MÜSSEN die Erweiterung in diesen Zertifikaten als kritisch kennzeichnen.
4.2.1.9	Zertifizierungsstellen dürfen das Feld "pathLenConstraint" nur dann enthalten, wenn der boolesche Wert "cA" und die Erweiterung für die Schlüsselverwendung das Bit "keyCertSign" bestätigt.
4.2.1.10	Die Erweiterung für Namenseinschränkungen, die nur in einem CA-Zertifikat verwendet werden MUSS, gibt einen Namensbereich an, in dem sich alle Subjektnamen in nachfolgenden Zertifikaten in einem Zertifizierungspfad befinden MÜSSEN.
4.2.1.10	Namenseinschränkungen: konforme Zertifizierungsstellen MÜSSEN diese Erweiterung als kritisch markieren
4.2.1.10	Konforme CAs dürfen KEINE Zertifikate ausstellen, wenn Namenseinschränkungen eine leere Sequenz sind. Das heißt, entweder das Feld allowedSubtrees oder die excludedSubtrees MÜSSEN vorhanden sein.
4.2.1.10	In diesem Profil werden die Felder Minimum und Maximum nicht mit Namensformen verwendet. Daher MUSS das Minimum null und das Maximum leer sein.
4.2.1.10	Die Syntax von iPAddress MUSS wie in Abschnitt 4.2.1.6 beschrieben sein, mit den folgenden Ergänzungen speziell für Namenseinschränkungen: Bei IPv4-Adressen MUSS das Feld iPAddress von GeneralName acht (8) Oktette enthalten, die im Stil von RFC 4632 (CIDR) codiert sind, um einen Adressbereich [RFC 4632] darzustellen. Bei IPv6-Adressen MUSS das iPAddress-Feld 32 ähnlich codierte Oktette enthalten.
4.2.1.11	Konforme CAs dürfen KEINE Zertifikate ausstellen, wenn Richtlinieneinschränkungen eine leere Sequenz sind. Das heißt, entweder das Feld "inhibitPolicyMapping" oder das Feld "requireexplizitPolicy" MUSS vorhanden sein.
4.2.1.11	Richtlinieneinschränkungen: Konforme Zertifizierungsstellen MÜSSEN diese Erweiterung als kritisch kennzeichnen.
4.2.1.13	Ein DistributionPoint DARF NICHT nur aus dem Feld "reasons" bestehen; entweder "distributionPoint" oder "cRLIssuer" MUSS vorhanden sein.
4.2.1.14	konforme Zertifizierungsstellen MÜSSEN diese Inhibit anyPolicy-Erweiterung als kritisch kennzeichnen.
4.2.1.15	Die neueste CRL-Erweiterung MUSS von konformen Zertifizierungsstellen als nicht kritisch gekennzeichnet werden.
4.2.2.1	Konforme CAs MÜSSEN diese Erweiterung für den Zugriff auf Zertifizierungsstellen als nicht kritisch kennzeichnen.
4.2.2.2	konforme Zertifizierungsstellen MÜSSEN diese Erweiterung für den Zugriff auf Informationen zum Antragsteller als nicht kritisch kennzeichnen.
4.1.2.5	Um anzugeben, dass ein Zertifikat kein klar definiertes Ablaufdatum hat, sollte „notAfter“ den Wert „GeneralizedTime“ (GeneralizedTime) von 99991231235959Z zugewiesen werden.
4.2.1.2	Damit Anwendungen das geeignete Endentitätszertifikat leichter identifizieren können, SOLLTE diese Erweiterung in allen Endentitätszertifikaten enthalten sein
4.2.1.3	Sofern vorhanden, SOLLTEN konforme Zertifizierungsstellen diese Erweiterung zur Schlüsselverwendung als kritisch kennzeichnen.
4.2.1.4	Konforme CAs DÜRFEN NICHT die Option „noticeRef“ verwenden.
4.2.1.4	Konforme CAs SOLLTE die UTF8String-Codierung für explizitText verwenden, KANN aber IA5String verwenden.
4.2.1.4	Der String „explicitText“ DARF KEINE Steuerzeichen enthalten (z.B. U+0000 bis U+001F und U+007F bis U+009F).
4.2.1.4	Bei Verwendung der UTF8String-Codierung MÜSSEN alle Zeichenfolgen gemäß der Unicode-Normalisierungsform C (NFC) normalisiert werden.
4.2.1.5	Jede in der Erweiterung für die Richtlinienzuordnung genannte AusstellerDomainPolicy SOLLTE auch in einer Erweiterung für Zertifikatsrichtlinien im selben Zertifikat geltend gemacht werden.
4.2.1.5	Übereinstimmende Zertifizierungsstellen SOLLTE diese Erweiterung zur Richtlinienzuordnung als kritisch kennzeichnen.
4.2.1.6	Wenn die Erweiterung „subjectAltName“ in ein Zertifikat mit einem nicht leeren Subjekt-Distinguished Name aufgenommen wird, sollten konforme Zertifizierungsstellen die Erweiterung „subjectAltName“ als nicht kritisch kennzeichnen.
4.2.1.7	Sofern vorhanden, SOLLTEN konforme Zertifizierungsstellen diese Namenserweiterung für den Aussteller als nicht kritisch kennzeichnen.
4.2.1.10	Für die Namensformulare "x400Address", "ediPartyName" oder "enrolledID" dürfen KEINE Namensbeschränkungen gelten.
4.2.1.12	Konformitätszertifizierungsstellen dürften diese Erweiterung NICHT als kritisch kennzeichnen, wenn eine ExtendedKeyUsage-KeypurposeId vorhanden ist.
4.2.1.13	Die Erweiterung CRL-Verteilungspunkte SOLLTE nicht kritisch sein
4.2.1.13	Falls vorhanden, SOLLTE DistributionPointName mindestens eine LDAP- oder HTTP-URI enthalten.
4.2.1.13	konforme CAs DÜRFEN „nameRelativeToCRLIssuer“ NICHT zur Angabe von Verteilungspunktnamen verwenden.
4.2.2.1	Wenn „id-ad-caIssuers accessMethod“ verwendet wird, SOLLTE mindestens eine Instanz eine accessLocation angeben, die ein HTTP [RFC 2616]- oder LDAP [RFC 4516]-URI ist.
7.2	Damit internationalisierte Domainnamen in der aktuellen Struktur berücksichtigt werden, MÜSSEN konforme Implementierungen internationalisierte Domainnamen vor der Speicherung im Feld "dNSName" in das ASCII-Format kompatibler Codierung (ASCII Compatible Encoding, ACE) konvertieren, bevor sie im Feld "dNSName" gespeichert werden.