3.3. Inclusione del timestamp del certificato firmato nell'handshake TLS

3.3. Inclusione del timestamp del certificato firmato nell'handshake TLS

I dati SCT corrispondenti al certificato dell'entità finale da almeno un log devono essere inclusi nell'handshake TLS, utilizzando un'estensione di certificato X509v3 come descritto di seguito, utilizzando un'estensione TLS (Sezione 7.4.1.4 di [RFC5246]) con tipo "signed_certificate_timestamp", o utilizzando OCSP Stapling (noto anche come estensione TLS "Certificate Status Request"; vedere [RFC6066]), dove la risposta include un'estensione OCSP con OID 1.3.6.1.4.1.11129.2.4.5 (vedere [RFC2560]) e corpo:

    SignedCertificateTimestampList ::= OCTET STRING

Almeno un SCT DEVE essere incluso. Gli operatori di server POSSONO includere più di un SCT.

Allo stesso modo, un'autorità di certificazione PUÒ inviare un Precertificato a più di un log, e tutti gli SCT ottenuti possono essere direttamente incorporati nel certificato finale, codificando la struttura SignedCertificateTimestampList come un OCTET STRING ASN.1 e inserendo i dati risultanti nel TBSCertificate come un'estensione di certificato X.509v3 (OID 1.3.6.1.4.1.11129.2.4.2). Al ricevimento del certificato, i client possono ricostruire il TBSCertificate originale per verificare la firma SCT.

Il contenuto dell'OCTET STRING ASN.1 incorporato in un'estensione OCSP o in un'estensione di certificato X509v3 è il seguente:

     opaque SerializedSCT<1..2^16-1>;

     struct {
         SerializedSCT sct_list <1..2^16-1>;
     } SignedCertificateTimestampList;

Qui, "SerializedSCT" è una stringa di byte opaca che contiene la struttura TLS serializzata. Questa codifica garantisce che i client TLS possano decodificare ogni SCT individualmente (cioè, se c'è un aggiornamento di versione, i client obsoleti possono ancora analizzare i vecchi SCT mentre saltano i nuovi SCT di cui non comprendono le versioni).

Allo stesso modo, gli SCT possono essere incorporati in un'estensione TLS. Vedere di seguito per i dettagli.

I client TLS DEVONO implementare tutti e tre i meccanismi. I server DEVONO implementare almeno uno dei tre meccanismi. Si noti che i server TLS esistenti possono generalmente utilizzare il meccanismo di estensione del certificato senza modifiche.

I server TLS dovrebbero inviare SCT da più log nel caso in cui uno o più log non siano accettabili per il client (ad esempio, se un log è stato cancellato per cattivo comportamento o ha subito una compromissione delle chiavi).