3.1. Entrées de journal

Toute personne peut soumettre un certificat à n'importe quel journal. Afin de permettre l'attribution de chaque certificat enregistré à son émetteur, le journal DOIT publier une liste de certificats racine acceptables (cette liste pourrait utilement être l'union des certificats racine approuvés par les principaux fournisseurs de navigateurs). Chaque certificat soumis DOIT être accompagné de tous les certificats supplémentaires requis pour vérifier la chaîne de certificats jusqu'à un certificat racine accepté. Le certificat racine lui-même PEUT être omis de la chaîne soumise au serveur de journal.

Alternativement, les autorités de certification (racine ainsi qu'intermédiaires) peuvent soumettre un certificat aux journaux avant l'émission. Pour ce faire, l'AC soumet un Précertificat que le journal peut utiliser pour créer une entrée qui sera valide par rapport au certificat émis. Le Précertificat est construit à partir du certificat à émettre en ajoutant une extension critique spéciale de poison (OID 1.3.6.1.4.1.11129.2.4.3, dont l'OCTET STRING extnValue contient des données NULL ASN.1 (0x05 0x00)) à la fin du TBSCertificate de l'entité finale (cette extension vise à garantir que le Précertificat ne peut pas être validé par un client X.509v3 standard) et en signant le TBSCertificate [RFC5280] résultant avec soit

un Certificat de Signature de Précertificat à usage spécial (CA:true, Extended Key Usage: Certificate Transparency, OID 1.3.6.1.4.1.11129.2.4.4). Le Certificat de Signature de Précertificat DOIT être directement certifié par le certificat AC (racine ou intermédiaire) qui signera finalement le TBSCertificate de l'entité finale produisant le certificat de l'entité finale (notez que le journal peut assouplir les règles de validation standard pour permettre cela, tant que le certificat émis sera valide),
ou, le certificat AC qui signera le certificat final.

Comme ci-dessus, la soumission du Précertificat DOIT être accompagnée du Certificat de Signature de Précertificat, s'il est utilisé, et de tous les certificats supplémentaires requis pour vérifier la chaîne jusqu'à un certificat racine accepté. La signature sur le TBSCertificate indique l'intention de l'autorité de certification d'émettre un certificat. Cette intention est considérée comme contraignante (c'est-à-dire que la mauvaise émission du Précertificat est considérée comme égale à la mauvaise émission du certificat final). Chaque journal vérifie la chaîne de signature du Précertificat et émet un Horodatage de Certificat Signé sur le TBSCertificate correspondant.

Les journaux DOIVENT vérifier que le certificat d'entité finale soumis ou le Précertificat possède une chaîne de signature valide remontant à un certificat AC racine approuvé, en utilisant la chaîne de certificats AC intermédiaires fournie par le soumetteur. Les journaux PEUVENT accepter des certificats qui ont expiré, ne sont pas encore valides, ont été révoqués ou ne sont pas entièrement valides selon les règles de vérification X.509 afin de tenir compte des particularités du logiciel d'émission de certificats AC. Cependant, les journaux DOIVENT refuser de publier des certificats sans chaîne valide vers une AC racine connue. Si un certificat est accepté et qu'un SCT est émis, le journal acceptant DOIT stocker toute la chaîne utilisée pour la vérification, y compris le certificat ou le Précertificat lui-même et y compris le certificat racine utilisé pour vérifier la chaîne (même s'il a été omis de la soumission), et DOIT présenter cette chaîne pour audit sur demande. Cette chaîne est requise pour empêcher une AC d'éviter le blâme en enregistrant une chaîne partielle ou vide. (Note : Cela exclut effectivement les certificats auto-signés et basés sur DANE jusqu'à ce qu'un mécanisme de contrôle du spam pour ces certificats soit trouvé. Les auteurs accueillent favorablement les suggestions.)

Chaque entrée de certificat dans un journal DOIT inclure les composants suivants :

    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;

Les journaux PEUVENT limiter la longueur de la chaîne qu'ils accepteront.

"entry_type" est le type de cette entrée. Les futures révisions de cette version de protocole peuvent ajouter de nouvelles valeurs LogEntryType. La Section 4 explique comment les clients doivent gérer les types d'entrées inconnus.

"leaf_certificate" est le certificat d'entité finale soumis pour audit.

"certificate_chain" est une chaîne de certificats supplémentaires requis pour vérifier le certificat d'entité finale. Le premier certificat DOIT certifier le certificat d'entité finale. Chaque certificat suivant DOIT certifier directement celui qui le précède. Le certificat final DOIT être un certificat racine accepté par le journal.

"pre_certificate" est le Précertificat soumis pour audit.

"precertificate_chain" est une chaîne de certificats supplémentaires requis pour vérifier la soumission du Précertificat. Le premier certificat PEUT être un Certificat de Signature de Précertificat valide et DOIT certifier le premier certificat. Chaque certificat suivant DOIT certifier directement celui qui le précède. Le certificat final DOIT être un certificat racine accepté par le journal.

3.1. Entrées de journal​

3.1. Entrées de journal