Zum Hauptinhalt springen

3.1. Log Entries (Log-Einträge)

3.1. Log Entries (Log-Einträge)​

Jeder kann ein Zertifikat an jedes Log senden. Um die Zuordnung jedes geloggten Zertifikats zu seinem Aussteller zu ermöglichen, SOLL das Log eine Liste akzeptabler Stammzertifikate veröffentlichen (nützlicherweise die Vereinigung der von großen Browser-Herstellern vertrauenswürdigen Stammzertifikate). Jedes eingereichte Zertifikat MUSS von allen zusätzlichen Zertifikaten begleitet sein, die nötig sind, die Kette bis zu einem akzeptierten Stammzertifikat zu verifizieren. Das Stammzertifikat selbst KANN in der an den Log-Server übermittelten Kette weggelassen werden.

Alternativ können (Stamm- wie auch Zwischen-)Zertifizierungsstellen ein Zertifikat vor der Ausstellung an Logs melden. Dazu reicht die CA ein Precertificate (Vorzertifikat) ein, mit dem das Log einen Eintrag erzeugen kann, der gegen das ausgestellte Zertifikat gültig ist. Das Precertificate wird aus dem auszustellenden Zertifikat gebaut, indem eine spezielle kritische Poison Extension (OID 1.3.6.1.4.1.11129.2.4.3, deren extnValue OCTET STRING ASN.1-NULL-Daten (0x05 0x00) enthält) an das End-Entity-TBSCertificate angehängt wird (diese Erweiterung soll sicherstellen, dass das Precertificate von einem Standard-X.509v3-Client nicht als gültig validiert werden kann), und das resultierende TBSCertificate [RFC5280] wird signiert mit entweder

  • einem speziellen Precertificate Signing Certificate (CA:true, Extended Key Usage: Certificate Transparency, OID 1.3.6.1.4.1.11129.2.4.4). Das Precertificate Signing Certificate MUSS direkt von dem (Stamm- oder Zwischen-)CA-Zertifikat beglaubigt sein, das letztlich das End-Entity-TBSCertificate signiert und so das End-Entity-Zertifikat erzeugt (das Log KANN Standard-Validierungsregeln lockern, solange das ausgestellte Zertifikat gültig sein wird), oder

  • dem CA-Zertifikat, das das endgültige Zertifikat signieren wird.

Wie oben MUSS die Precertificate-Einreichung das Precertificate Signing Certificate enthalten, falls verwendet, sowie alle weiteren Zertifikate, die nötig sind, die Kette bis zu einem akzeptierten Stamm zu verifizieren. Die Signatur auf dem TBSCertificate drückt die Absicht der CA aus, ein Zertifikat auszustellen. Diese Absicht gilt als bindend (d. h. Fehlausstellung des Precertificate entspricht Fehlausstellung des Endzertifikats). Jedes Log verifiziert die Precertificate-Signaturkette und stellt einen Signed Certificate Timestamp für das entsprechende TBSCertificate aus.

Logs MÜSSEN verifizieren, dass das eingereichte End-Entity-Zertifikat oder Precertificate eine gültige Signaturkette bis zu einem vertrauenswürdigen Stamm-CA-Zertifikat hat, unter Verwendung der vom Einreicher gelieferten Zwischen-CA-Kette. Logs KÖNNEN Zertifikate akzeptieren, die abgelaufen sind, noch nicht gültig sind, widerrufen wurden oder nach X.509-Regeln nicht vollständig gültig sind, um Eigenheiten von CA-Ausstellungssoftware zu berücksichtigen. Logs MÜSSEN jedoch die Veröffentlichung von Zertifikaten ohne gültige Kette zu einem bekannten Stamm-CA ablehnen. Wird ein Zertifikat akzeptiert und ein SCT ausgestellt, MUSS das akzeptierende Log die gesamte zur Verifikation verwendete Kette speichern, einschließlich des Zertifikats oder Precertificate selbst und des zur Kettenverifikation genutzten Stammzertifikats (auch wenn es in der Einreichung fehlte), und MUSS diese Kette auf Anfrage zur Prüfung bereitstellen. Diese Kette verhindert, dass eine CA durch partielle oder leere Ketten der Verantwortung entgeht. (Hinweis: Dies schließt selbstsignierte und DANE-basierte Zertifikate faktisch aus, bis ein Mechanismus zur Spam-Kontrolle dafür existiert. Die Autoren nehmen gern Vorschläge entgegen.)

Jeder Zertifikatseintrag in einem Log MUSS die folgenden Komponenten enthalten:

    enum { x509_entry(0), precert_entry(1), (65535) } LogEntryType;

    struct {
        LogEntryType entry_type;
        select (entry_type) {
            case x509_entry: X509ChainEntry;
            case precert_entry: PrecertChainEntry;
        } entry;
    } LogEntry;

    opaque ASN.1Cert<1..2^24-1>;

    struct {
        ASN.1Cert leaf_certificate;
        ASN.1Cert certificate_chain<0..2^24-1>;
    } X509ChainEntry;

    struct {
        ASN.1Cert pre_certificate;
        ASN.1Cert precertificate_chain<0..2^24-1>;
    } PrecertChainEntry;

Logs KÖNNEN die akzeptierte Kettenlänge begrenzen.

entry_type ist der Typ dieses Eintrags. Künftige Revisionen dieser Protokollversion können neue LogEntryType-Werte hinzufügen. Abschnitt 4 erläutert, wie Clients unbekannte Eintragstypen behandeln sollen.

leaf_certificate ist das zur Prüfung eingereichte End-Entity-Zertifikat.

certificate_chain ist eine Kette zusätzlicher Zertifikate, die nötig sind, um das End-Entity-Zertifikat zu verifizieren. Das erste Zertifikat MUSS das End-Entity-Zertifikat beglaubigen. Jedes folgende Zertifikat MUSS das unmittelbar vorhergehende direkt beglaubigen. Das letzte Zertifikat MUSS ein vom Log akzeptiertes Stammzertifikat sein.

pre_certificate ist das zur Prüfung eingereichte Precertificate.

precertificate_chain ist eine Kette zusätzlicher Zertifikate, die nötig sind, die Precertificate-Einreichung zu verifizieren. Das erste Zertifikat KANN ein gültiges Precertificate Signing Certificate sein und MUSS das Precertificate beglaubigen. Jedes folgende Zertifikat MUSS das vorhergehende direkt beglaubigen. Das letzte Zertifikat MUSS ein vom Log akzeptiertes Stammzertifikat sein.

Letztes Update am