RFC-Compliance

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

CA Service setzt die folgenden Anforderungen aus RFC 5280 durch.

RFC 5280-Abschnitt	Lint-Klausel
4.1.1.2	Der „signatureAlgorithm“ im Zertifikat MUSS denselben Algorithmusbezeichner wie das Feld „signature“ in der Sequenz „tbsCertificate“ (Abschnitt 4.1.2.3) enthalten.
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	Konforme Zertifizierungsstellen DÜRFEN KEINE serialNumber-Werte 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 Gültigkeitsdaten von Zertifikaten bis zum Jahr 2049 immer als UTCTime codieren.
4.1.2.5	Wenn ein Zertifikat kein genau definiertes Ablaufdatum hat, sollte dem notAfter-Feld der GeneralizedTime-Wert 99991231235959Z zugewiesen werden.
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	GeneralizedTime-Werte MÜSSEN in Greenwich Mean Time (Zulu) angegeben 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. wenn die Erweiterung „Basic Constraints“ (siehe Abschnitt 4.2.1.9) vorhanden ist und der Wert von „cA“ auf „TRUE“ gesetzt ist), MUSS das Subjektfeld mit einem nicht leeren Distinguished Name gefüllt werden, der mit dem Inhalt des Ausstellerfelds (Abschnitt 4.1.2.4) in allen von der Subjekt-Zertifizierungsstelle ausgestellten Zertifikaten übereinstimmt.
4.1.2.8	Felder mit eindeutigen Kennzeichnungen DÜRFEN nur bei Version 2 oder 3 angezeigt werden.
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 nicht mehr als eine Instanz einer bestimmten Erweiterung enthalten.
4.2	Wenn die Zertifizierungsstelle Zertifikate mit einer leeren Sequenz für das Antragstellerfeld ausstellt, MUSS sie die Erweiterung „Alternativer Antragstellername“ unterstützen.
4.2.1.1	Das Feld „keyIdentifier“ der Erweiterung „authorityKeyIdentifier“ MUSS in allen Zertifikaten enthalten sein, die von konformen Zertifizierungsstellen generiert werden, um die Erstellung von Zertifizierungspfaden zu erleichtern.
4.2.1.1	Konforme CAs MÜSSEN die Erweiterung „authorityKeyIdentifier“ als nicht kritisch kennzeichnen.
4.2.1.2	Um die Erstellung des Zertifizierungspfads zu erleichtern, MUSS authorityKeyIdentifier in allen konformen CA-Zertifikaten enthalten sein, d. h. in allen Zertifikaten, die die Erweiterung „basicConstraints“ (Abschnitt 4.2.1.9) enthalten, in denen der Wert von „cA“ auf „TRUE“ gesetzt ist.
4.2.1.2	Konforme CAs MÜSSEN die Erweiterung für die Subjektschlüssel-ID als nicht kritisch kennzeichnen.
4.2.1.2	Damit Anwendungen das richtige Endentitätszertifikat leichter identifizieren können, SOLLTE diese Erweiterung in allen Endentitätszertifikaten enthalten sein.
4.2.1.3	Wenn das „keyCertSign“-Bit gesetzt ist, MUSS auch das „cA“-Bit in der Erweiterung „basicConstraints“ (Abschnitt 4.2.1.9) gesetzt sein.
4.2.1.3	Wenn die Erweiterung „keyUsage“ in einem Zertifikat enthalten ist, MUSS mindestens eines der Bits auf 1 gesetzt sein.
4.2.1.3	Falls vorhanden, SOLLTEN konforme Zertifizierungsstellen diese Erweiterung für die Schlüsselverwendung als kritisch kennzeichnen.
4.2.1.4	Eine Zertifikatsrichtlinien-OID darf in einer Zertifikatsrichtlinien-Erweiterung nicht mehr als einmal vorkommen.
4.2.1.4	Wenn Qualifizierer mit der Sonderrichtlinie „anyPolicy“ verwendet werden, MÜSSEN sie auf die in diesem Abschnitt genannten Qualifizierer beschränkt sein.
4.2.1.4	Konforme Zertifizierungsstellen SOLLTEN die Option „noticeRef“ NICHT verwenden.
4.2.1.4	Konforme Zertifizierungsstellen SOLLTEN die UTF8String-Codierung für explicitText verwenden, DÜRFEN aber auch IA5String verwenden.
4.2.1.4	Der String „explicitText“ SOLLTE 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, SOLLTEN alle Zeichenfolgen gemäß der Unicode-Normalisierungsform C (NFC) normalisiert werden.
4.2.1.5	Richtlinien DÜRFEN NICHT dem Sonderwert „anyPolicy“ zugeordnet werden.
4.2.1.5	Jede in der Erweiterung für Richtlinienzuordnungen genannte „issuerDomainPolicy“ SOLLTE auch in einer Erweiterung für Zertifikatsrichtlinien im selben Zertifikat bestätigt werden.
4.2.1.5	Konforme CAs SOLLTEN diese Policy Mappings-Erweiterung als kritisch kennzeichnen.
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 Feld „Subject“ eine leere Sequenz enthält, MUSS die ausstellende Zertifizierungsstelle eine Erweiterung „subjectAltName“ einfügen, 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 IPv4, wie in [RFC 791] angegeben, MUSS der Oktett-String genau vier Oktette enthalten. Für IP-Version 6, wie in [RFC 2460] angegeben, MUSS der Oktett-String genau 16 Oktette enthalten.
4.2.1.6	Wenn die Erweiterung „subjectAltName“ ein DNS-Label enthält, MUSS der Domainname im dNSName (ein IA5String) gespeichert werden.
4.2.1.6	SANs: Der dNSName MUSS die „bevorzugte Namenssyntax“ haben.
4.2.1.6	subjectAltName-Erweiterungen mit einem dNSName von „ “ DÜRFEN NICHT verwendet werden.
4.2.1.6	Die DNS-Darstellung für Internet-E-Mail-Adressen (subscriber.example.com anstelle von [e-mail]) DARF NICHT verwendet werden.
4.2.1.6	Wenn die Erweiterung „subjectAltName“ einen URI enthält, MUSS der Name in „uniformResourceIdentifier“ (ein IA5String) gespeichert werden.
4.2.1.6	SAN-URIs: Der Name darf kein relativer URI sein und muss der in [RFC 3986] angegebenen URI-Syntax und den Codierungsregeln entsprechen.
4.2.1.6	SAN-URIs: Der Name MUSS sowohl ein Schema (z.B. „http“ oder „ftp“) und einen schemabezogenen Teil.
4.2.1.6	SAN-URIs, die eine Autorität ([RFC 3986], Abschnitt 3.2) enthalten, MÜSSEN einen vollqualifizierten 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.6	Wenn die Erweiterung „subjectAltName“ in ein Zertifikat mit einem nicht leeren Distinguished Name für den Zertifikatsinhaber aufgenommen wird, SOLLTEN konforme Zertifizierungsstellen die Erweiterung „subjectAltName“ als nicht kritisch kennzeichnen.
4.2.1.7	Der alternative Name des Ausstellers MUSS wie in 4.2.1.6 codiert werden.
4.2.1.7	Falls vorhanden, SOLLTEN konforme Zertifizierungsstellen diese Erweiterung für alternative Ausstellernamen als nicht kritisch kennzeichnen.
4.2.1.8	Attribute des Betreffverzeichnisses: Konforme CAs MÜSSEN diese Erweiterung als nicht kritisch markieren.
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 alle CA-Zertifikate aufnehmen, die öffentliche Schlüssel enthalten, die zum Validieren digitaler Signaturen in Zertifikaten verwendet werden, und MÜSSEN die Erweiterung in solchen Zertifikaten als kritisch kennzeichnen.
4.2.1.9	Zertifizierungsstellen DÜRFEN das Feld „pathLenConstraint“ NUR dann einfügen, wenn der boolesche Wert „cA“ bestätigt wird und die Erweiterung „key usage“ das Bit „keyCertSign“ bestätigt.
4.2.1.10	Die Erweiterung für Namenseinschränkungen, die nur in einem CA-Zertifikat verwendet werden darf, gibt einen Namespace an, in dem sich alle Antragstellernamen in nachfolgenden Zertifikaten in einem Zertifizierungspfad befinden müssen.
4.2.1.10	Namenseinschränkungen: Konforme CAs MÜSSEN diese Erweiterung als kritisch markieren.
4.2.1.10	Konforme Zertifizierungsstellen DÜRFEN KEINE Zertifikate ausstellen, bei denen die Namenseinschränkungen eine leere Sequenz sind. Das bedeutet, dass entweder das Feld „permittedSubtrees“ oder „excludedSubtrees“ vorhanden sein MUSS.
4.2.1.10	In diesem Profil werden die Felder „minimum“ und „maximum“ nicht mit Namensformen verwendet. Daher MUSS „minimum“ null sein und „maximum“ darf nicht vorhanden sein.
4.2.1.10	Die Syntax von iPAddress MUSS der in Abschnitt 4.2.1.6 beschriebenen Syntax entsprechen. Für Namensbeschränkungen gelten jedoch die folgenden zusätzlichen Anforderungen: Für 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.10	Es SOLLTEN keine Namensbeschränkungen für die Namensformen „x400Address“, „ediPartyName“ oder „registeredID“ auferlegt werden.
4.2.1.11	Konforme Zertifizierungsstellen DÜRFEN KEINE Zertifikate ausstellen, bei denen die Richtlinienbeschränkungen eine leere Sequenz sind. Das bedeutet, dass entweder das Feld „inhibitPolicyMapping“ oder das Feld „requireExplicitPolicy“ vorhanden sein MUSS.
4.2.1.11	Richtlinieneinschränkungen: Konforme Zertifizierungsstellen MÜSSEN diese Erweiterung als kritisch kennzeichnen.
4.2.1.12	Konforme CAs SOLLTEN diese Erweiterung NICHT als kritisch markieren, wenn die KeyPurposeId „anyExtendedKeyUsage“ vorhanden ist.
4.2.1.13	Ein DistributionPoint darf nicht nur aus dem Feld „reasons“ bestehen. Entweder „distributionPoint“ oder „cRLIssuer“ muss vorhanden sein.
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 nameRelativeToCRLIssuer NICHT verwenden, um Namen von Verteilungspunkten anzugeben.
4.2.1.14	Konforme CAs MÜSSEN diese Inhibit anyPolicy-Erweiterung als kritisch markieren.
4.2.1.15	Die Erweiterung „Freshest CRL“ MUSS von konformen Zertifizierungsstellen als nicht kritisch gekennzeichnet werden.
4.2.2.1	Konforme CAs MÜSSEN diese AIA-Erweiterung (Authority Information Access) als nicht kritisch kennzeichnen.
4.2.2.1	Wenn die accessMethod „id-ad-caIssuers“ verwendet wird, SOLLTE in mindestens einer Instanz eine accessLocation angegeben werden, die ein HTTP- [RFC 2616] oder LDAP- [RFC 4516] URI ist.
4.2.2.2	Konforme CAs MÜSSEN diese Erweiterung für den Zugriff auf Informationen zum Betreff als nicht kritisch kennzeichnen.
7.2	Um internationalisierte Domainnamen in der aktuellen Struktur zu berücksichtigen, MÜSSEN konforme Implementierungen internationalisierte Domainnamen in das ASCII-kompatible Codierungsformat (ACE) konvertieren, wie in Abschnitt 4 von RFC 3490 angegeben, bevor sie im Feld „dNSName“ gespeichert werden.