Passa al contenuto principale

3.1. Voci di log

3.1. Voci di log​

Chiunque può inviare un certificato a qualsiasi log. Per consentire l'attribuzione di ogni certificato registrato al suo emittente, il log DEVE pubblicare un elenco di certificati radice accettabili (questo elenco potrebbe utilmente essere l'unione dei certificati radice ritenuti affidabili dai principali fornitori di browser). Ogni certificato inviato DEVE essere accompagnato da tutti i certificati aggiuntivi necessari per verificare la catena di certificati fino a un certificato radice accettato. Il certificato radice stesso PUÒ essere omesso dalla catena inviata al server di log.

In alternativa, le autorità di certificazione (radice e intermedie) possono inviare un certificato ai log prima dell'emissione. Per farlo, la CA invia un Precertificato che il log può utilizzare per creare una voce che sarà valida rispetto al certificato emesso. Il Precertificato è costruito dal certificato da emettere aggiungendo un'estensione critica speciale di veleno (OID 1.3.6.1.4.1.11129.2.4.3, il cui OCTET STRING extnValue contiene dati NULL ASN.1 (0x05 0x00)) alla fine del TBSCertificate dell'entità finale (questa estensione serve a garantire che il Precertificato non possa essere convalidato da un client X.509v3 standard) e firmando il TBSCertificate [RFC5280] risultante con

  • un Certificato di Firma Precertificato per scopo speciale (CA:true, Extended Key Usage: Certificate Transparency, OID 1.3.6.1.4.1.11129.2.4.4). Il Certificato di Firma Precertificato DEVE essere direttamente certificato dal certificato CA (radice o intermedio) che alla fine firmerà il TBSCertificate dell'entità finale producendo il certificato dell'entità finale (si noti che il log può rilassare le regole di convalida standard per consentire ciò, purché il certificato emesso sia valido),

  • oppure, il certificato CA che firmerà il certificato finale.

Come sopra, l'invio del Precertificato DEVE essere accompagnato dal Certificato di Firma Precertificato, se utilizzato, e da tutti i certificati aggiuntivi necessari per verificare la catena fino a un certificato radice accettato. La firma sul TBSCertificate indica l'intenzione dell'autorità di certificazione di emettere un certificato. Questa intenzione è considerata vincolante (cioè, l'emissione errata del Precertificato è considerata uguale all'emissione errata del certificato finale). Ogni log verifica la catena di firme del Precertificato ed emette un Timestamp di Certificato Firmato sul TBSCertificate corrispondente.

I log DEVONO verificare che il certificato dell'entità finale inviato o il Precertificato abbia una catena di firme valida che risale a un certificato CA radice affidabile, utilizzando la catena di certificati CA intermedi fornita dal mittente. I log POSSONO accettare certificati scaduti, non ancora validi, revocati o altrimenti non completamente validi secondo le regole di verifica X.509 per accogliere le peculiarità del software di emissione dei certificati CA. Tuttavia, i log DEVONO rifiutare di pubblicare certificati senza una catena valida a una CA radice conosciuta. Se un certificato è accettato e viene emesso un SCT, il log accettante DEVE memorizzare l'intera catena utilizzata per la verifica, incluso il certificato o il Precertificato stesso e incluso il certificato radice utilizzato per verificare la catena (anche se è stato omesso dall'invio), e DEVE presentare questa catena per l'audit su richiesta. Questa catena è necessaria per impedire a una CA di evitare la responsabilità registrando una catena parziale o vuota. (Nota: Questo esclude effettivamente i certificati auto-firmati e basati su DANE fino a quando non viene trovato un meccanismo per controllare lo spam per quei certificati. Gli autori accolgono suggerimenti.)

Ogni voce di certificato in un log DEVE includere i seguenti componenti:

    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;

I log POSSONO limitare la lunghezza della catena che accetteranno.

"entry_type" è il tipo di questa voce. Le future revisioni di questa versione del protocollo possono aggiungere nuovi valori LogEntryType. La Sezione 4 spiega come i client devono gestire i tipi di voce sconosciuti.

"leaf_certificate" è il certificato dell'entità finale inviato per l'audit.

"certificate_chain" è una catena di certificati aggiuntivi necessari per verificare il certificato dell'entità finale. Il primo certificato DEVE certificare il certificato dell'entità finale. Ogni certificato successivo DEVE certificare direttamente quello che lo precede. Il certificato finale DEVE essere un certificato radice accettato dal log.

"pre_certificate" è il Precertificato inviato per l'audit.

"precertificate_chain" è una catena di certificati aggiuntivi necessari per verificare l'invio del Precertificato. Il primo certificato PUÒ essere un Certificato di Firma Precertificato valido e DEVE certificare il primo certificato. Ogni certificato successivo DEVE certificare direttamente quello che lo precede. Il certificato finale DEVE essere un certificato radice accettato dal log.

Ultimo aggiornamento il