RFC-Compliance

Der Certificate Authority Service verwendet das ZLint-Tool, um sicherzustellen, dass X.509-Zertifikate gemäß den Regeln von RFC 5280 gültig sind. Der CA Service erzwingt jedoch nicht alle Anforderungen von RFC 5280. Es ist möglich, dass eine mit dem CA Service erstellte Zertifizierungsstelle ein nicht konformes Zertifikat ausstellt.

CA Service unterliegt den folgenden RFC 5280-Anforderungen.

Abschnitt in RFC 5280	Lint-Klausel
4.1.1.2	Der „signatureAlgorithm“ im Zertifikat MUSS dieselbe Algorithmus-ID wie das Signaturfeld in der Sequenz „tbsCertificate“ enthalten (Abschnitt 4.1.2.3).
4.1.2.1	Wenn Erweiterungen verwendet werden, wie in diesem Profil erwartet, MUSS die Version 3 sein (Wert 2).
4.1.2.2	Die Seriennummer MUSS eine positive Ganzzahl sein, die von der Zertifizierungsstelle jedem Zertifikat zugewiesen wird.
4.1.2.2	Konforme Zertifizierungsstellen DÜRFEN KEINE Werte für „serialNumber“ verwenden, die länger als 20 Oktette sind.
4.1.2.4	Das Feld „Aussteller“ MUSS einen nicht leeren Distinguished Name (DN) enthalten.
4.1.2.5	Zertifizierungsstellen, die diesem Profil entsprechen, MÜSSEN die Gültigkeitsdaten von Zertifikaten bis zum Jahr 2049 immer als UTC-Zeit codieren.
4.1.2.5.1	UTCTime-Werte MÜSSEN in Greenwich Mean Time (Zulu) angegeben werden.
4.1.2.5.1	UTCTime-Werte MÜSSEN Sekunden enthalten.
4.1.2.5.2	Werte vom Typ „GeneralizedTime“ MÜSSEN in Greenwich Mean Time (Zulu) ausgedrückt werden.
4.1.2.5.2	GeneralizedTime MUSS Sekunden enthalten
4.1.2.5.2	Werte vom Typ „GeneralizedTime“ DÜRFEN KEINE Sekundenbruchteile enthalten.
4.1.2.6	Wenn das Subjekt eine Zertifizierungsstelle ist (z.B. die Erweiterung „Basic Constraints“, wie in Abschnitt 4.2.1.9 beschrieben, vorhanden ist und der Wert von „cA“ TRUE ist), MUSS das Feld „Subject“ mit einem nicht leeren Distinguished Name ausgefüllt sein, der mit dem Inhalt des Felds „Aussteller“ (Abschnitt 4.1.2.4) in allen von der Zertifizierungsstelle ausgestellten Zertifikaten übereinstimmt.
4.1.2.8	Felder für eindeutige Kennzeichnungen MÜSSEN nur angezeigt werden, wenn die Version 2 oder 3 ist.
4.1.2.8	Zertifizierungsstellen, die diesem Profil entsprechen, DÜRFEN KEINE Zertifikate mit eindeutigen Kennungen generieren.
4.1.2.9	Das Feld „Extensions“ darf nur angezeigt werden, wenn die Version 3 ist.
4.2	Ein Zertifikat darf KEINE Instanz einer bestimmten Erweiterung enthalten.
4.2	Wenn die Zertifizierungsstelle Zertifikate mit einer leeren Sequenz für das Subject-Feld ausstellt, MUSS sie die Erweiterung „subjectAlternativeName“ unterstützen.
4.2.1.1	Das Feld „keyIdentifier“ der Erweiterung „authorityKeyIdentifier“ MUSS in allen Zertifikaten enthalten sein, die von konformen Zertifizierungsstellen generiert wurden, um die Erstellung des Zertifizierungspfads zu erleichtern.
4.2.1.1	Konforme Zertifizierungsstellen MÜSSEN die Erweiterung „authorityKeyIdentifier“ als nicht kritisch kennzeichnen.
4.2.1.2	Zur Erleichterung der Erstellung des Zertifizierungspfads MUSS „authorityKeyIdentifier“ in allen konformen CA-Zertifikaten enthalten sein, d. h. in allen Zertifikaten, die die Erweiterung „Basic Constraints“ (Abschnitt 4.2.1.9) enthalten, bei der der Wert von „cA“ TRUE ist.
4.2.1.2	Konforme Zertifizierungsstellen MÜSSEN die Erweiterung der Subjektschlüssel-ID als nicht kritisch kennzeichnen.
4.2.1.3	Wenn das Bit „keyCertSign“ aktiviert ist, MUSS auch das Bit „cA“ in der Erweiterung „Basic Constraints“ (Abschnitt 4.2.1.9) aktiviert sein.
4.2.1.3	Wenn die keyUsage-Erweiterung in einem Zertifikat enthalten ist, MUSS mindestens eines der Bits auf „1“ gesetzt sein.
4.2.1.4	Eine OID für Zertifikatsrichtlinien darf in einer Erweiterung für Zertifikatsrichtlinien NICHT mehr als einmal vorkommen.
4.2.1.4	Wenn Einschränkungen mit der speziellen Richtlinie „anyPolicy“ verwendet werden, MÜSSEN sie auf die in diesem Abschnitt aufgeführten Einschränkungen beschränkt sein.
4.2.1.5	Richtlinien dürfen NICHT auf den Sonderwert „anyPolicy“ oder von diesem abgeleitet werden.
4.2.1.6	Wenn solche Identitäten (alles in einem SAN) an ein Zertifikat gebunden werden sollen, MUSS die Erweiterung „Subject Alternative Name“ (oder „Issuer Alternative Name“) verwendet werden.
4.2.1.6	Wenn das Subject-Feld eine leere Sequenz enthält, MUSS die ausstellende Zertifizierungsstelle eine subjectAltName-Erweiterung angeben, die als kritisch gekennzeichnet ist.
4.2.1.6	Wenn die Erweiterung „subjectAltName“ eine Internet-E-Mail-Adresse enthält, MUSS die Adresse in rfc822Name gespeichert werden.
4.2.1.6	Für IP-Version 4 muss der Oktett-String gemäß [RFC 791] genau vier Oktette enthalten. Für IP-Version 6 muss der Oktettstring gemäß [RFC 2460] genau 16 Oktette enthalten.
4.2.1.6	Wenn die Erweiterung „subjectAltName“ ein Domain Name System-Label enthält, MUSS der Domainname im dNSName (einem IA5String) gespeichert werden.
4.2.1.6	SANs: Der dNSName MUSS in der „preferred name syntax“ (Syntax für bevorzugte Namen) sein.
4.2.1.6	subjectAltName-Erweiterungen mit dem DNS-Namen „“ DÜRFEN NICHT verwendet werden.
4.2.1.6	Die DNS-Darstellung für Internet-E-Mail-Adressen (subscriber.beispiel.de anstelle von [e-mail]) DARF NICHT verwendet werden.
4.2.1.6	Wenn die subjectAltName-Erweiterung einen URI enthält, MUSS der Name im uniformResourceIdentifier (einem IA5String) gespeichert werden.
4.2.1.6	SAN-URIs: Der Name DARF KEIN relativer URI sein und MUSS den in [RFC 3986] angegebenen URI-Syntax- und Codierungsregeln entsprechen.
4.2.1.6	SAN-URIs: Der Name MUSS sowohl ein Schema (z.B. „http“ oder „ftp“) und einen schemspezifischen Teil.
4.2.1.6	SAN-URIs, die eine Autorität enthalten ([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 mit 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 Attributes: 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 Zertifizierungsstellen MÜSSEN diese Erweiterung in allen Zertifizierungsstellenzertifikaten angeben, die öffentliche Schlüssel enthalten, die zum Validieren digitaler Signaturen in Zertifikaten verwendet werden. Außerdem MÜSSEN sie die Erweiterung in solchen Zertifikaten als kritisch kennzeichnen.
4.2.1.9	Zertifizierungsstellen DÜRFEN das Feld „pathLenConstraint“ NICHT enthalten, es sei denn, die Boolesche Variable „cA“ ist aktiviert und die Erweiterung „Key Usage“ enthält das Bit „keyCertSign“.
4.2.1.10	Die Erweiterung „Namensbeschränkungen“, die NUR in einem CA-Zertifikat verwendet werden darf, gibt einen Namensraum an, in dem sich alle Antragstellernamen in nachfolgenden Zertifikaten in einem Zertifizierungspfad befinden MÜSSEN.
4.2.1.10	Namenseinschränkungen: Konforme Zertifizierungsstellen MÜSSEN diese Erweiterung als kritisch kennzeichnen.
4.2.1.10	Konforme Zertifizierungsstellen DÜRFEN KEINE Zertifikate ausstellen, bei denen „Namenseinschränkungen“ eine leere Sequenz ist. Das Feld „permittedSubtrees“ oder „excludedSubtrees“ MUSS vorhanden sein.
4.2.1.10	In diesem Profil werden die Felder „Minimum“ und „Maximum“ nicht für Namensformulare verwendet. Daher muss das Minimum „0“ sein und das Maximum darf nicht vorhanden sein.
4.2.1.10	Die Syntax von „iPAddress“ MUSS der in Abschnitt 4.2.1.6 beschriebenen entsprechen, wobei die folgenden Ergänzungen speziell für Namensbeschränkungen gelten: 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 darzustellen [RFC 4632]. Bei IPv6-Adressen MUSS das Feld „iPAddress“ 32 Oktette enthalten, die auf ähnliche Weise codiert sind.
4.2.1.11	Konforme Zertifizierungsstellen DÜRFEN KEINE Zertifikate ausstellen, wenn die Richtlinieneinschränkungen eine leere Sequenz sind. Das Feld „inhibitPolicyMapping“ oder das Feld „requireExplicitPolicy“ 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“ MÜSSEN vorhanden sein.
4.2.1.14	Konforme Zertifizierungsstellen MÜSSEN diese Erweiterung „Inhibit anyPolicy“ als kritisch kennzeichnen.
4.2.1.15	Die Freshest CRL-Erweiterung MUSS von konformen Zertifizierungsstellen als nicht kritisch gekennzeichnet werden.
4.2.2.1	Konforme Zertifizierungsstellen MÜSSEN diese AIA-Erweiterung als nicht kritisch kennzeichnen.
4.2.2.2	Konforme Zertifizierungsstellen MÜSSEN diese Erweiterung für den Zugriff auf personenbezogene Daten als nicht kritisch kennzeichnen.
4.1.2.5	Wenn ein Zertifikat kein klar definiertes Ablaufdatum hat, sollte dem Attribut „notAfter“ der GeneralizedTime-Wert „99991231235959Z“ zugewiesen werden.
4.2.1.2	Um Anwendungen bei der Identifizierung des entsprechenden Endentitätszertifikats zu unterstützen, sollte diese Erweiterung in allen Endentitätszertifikaten enthalten sein.
4.2.1.3	Konforme Zertifizierungsstellen MÜSSEN diese Schlüsselverwendungserweiterung als kritisch kennzeichnen, sofern vorhanden.
4.2.1.4	Konforme Zertifizierungsstellen DÜRFEN die Option „noticeRef“ NICHT verwenden.
4.2.1.4	Konforme Zertifizierungsstellen MÜSSEN die UTF8String-Codierung für „explicitText“ verwenden, KÖNNEN aber auch 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	Wenn die UTF8String-Codierung verwendet wird, MÜSSEN alle Zeichenfolgen gemäß Unicode-Normalisierungsform C (NFC) normalisiert werden.
4.2.1.5	Jede in der Erweiterung „Richtlinienzuordnungen“ angegebene „Ausstellerdomainrichtlinie“ MUSS auch in einer Erweiterung der Zertifikatsrichtlinien im selben Zertifikat angegeben werden.
4.2.1.5	Konforme Zertifizierungsstellen MÜSSEN diese Erweiterung für Richtlinienzuordnungen als kritisch kennzeichnen.
4.2.1.6	Wenn die Erweiterung „subjectAltName“ in einem Zertifikat mit einem nicht leeren Distinguished Name des Zertifikatsinhabers enthalten ist, MÜSSEN konforme Zertifizierungsstellen die Erweiterung „subjectAltName“ als nicht kritisch kennzeichnen.
4.2.1.7	Konforme Zertifizierungsstellen MÜSSEN diese Erweiterung für den alternativen Namen des Ausstellers als nicht kritisch kennzeichnen, sofern vorhanden.
4.2.1.10	Es sollten KEINE Namenseinschränkungen für die Namensformate „x400Address“, „ediPartyName“ oder „registeredID“ gelten.
4.2.1.12	Konforme Zertifizierungsstellen DÜRFEN diese Erweiterung NICHT als kritisch kennzeichnen, wenn die KeyPurposeId „anyExtendedKeyUsage“ vorhanden ist.
4.2.1.13	Die Erweiterung „CRL Distribution Points“ sollte NICHT kritisch sein.
4.2.1.13	Wenn vorhanden, sollte „DistributionPointName“ mindestens einen LDAP- oder HTTP-URI enthalten.
4.2.1.13	Konforme Zertifizierungsstellen sollten den Namen „nameRelativeToCRLIssuer“ NICHT verwenden, um Namen von Bereitstellungspunkten anzugeben.
4.2.2.1	Wenn die accessMethod-ID „id-ad-caIssuers“ verwendet wird, sollte für mindestens eine Instanz ein „accessLocation“ angegeben werden, der ein HTTP-URI [RFC 2616] oder LDAP-URI [RFC 4516] ist.
7,2	Damit internationalisierte Domainnamen in der aktuellen Struktur berücksichtigt werden können, MÜSSEN konforme Implementierungen internationalisierte Domainnamen vor dem Speichern im Feld „dNSName“ in das ASCII-kompatible Codierungsformat (ACE) konvertieren, wie in Abschnitt 4 von RFC 3490 angegeben.