CRL optimization: verify CRL signatures once, up-front.

Aperta
  • Qualcosa non va?
#81 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
38/100
Tipo di issue
Refactoring
Chiarezza
Abbastanza chiara
Stato di attività
Ferma
Stack tecnologico
rust
Ambito
cryptography, security

Direzione di ricerca

Inizia dalla gestione delle CRL nella pull request indicata e in src/verify_cert.rs intorno alle righe 219-222, quindi esamina RFC 5280 §6.3.3. Il lavoro è completato quando la convalida della firma della CRL viene eseguita una volta durante il caricamento o la preparazione, anziché a ogni controllo di revoca, preservando al contempo la relazione richiesta con il trust-anchor.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

In https://github.com/rustls/webpki/pull/66 we've staged support for using Certificate Revocation Lists (CRLs) to make revocation decisions during path building.

The code in that branch performs CRL signature verification as part of verifying the signatures on the end-entity to trust anchor path that was found from path building: https://github.com/rustls/webpki/blob/8425fa3f54ab7a8790a572023910e5bc850f55cc/src/verify_cert.rs#L219C10-L222

This was done for two a few reasons:

  1. It was easier to integrate with the existing path building code used for certificate validation. That code relies on building a linked list from trust anchor -> intermediate certificate(s) -> end entity certificate. It's not super trivial to generalize to building a path from trust anchor to CRL and we'd need that ability to verify a CRL signature outside the context of cert validation (e.g. when loading the CRL).
  2. From an end-user perspective, it's appealing to be able to load CRLs without needing to first parse each of the issuers associated with the CRL (and the issuers of the issuers up to a root). E.g. with the current implementation its easy to load CRLs for intermediate certificates without needing to source those intermediates up-front, if the TLS handshake provides intermediates associated with loaded CRLs they can be used during path building without extra effort up-front.
  3. On the topic of CRL processing, RFC 5280 §6.3.3 says:

(f) Obtain and validate the certification path for the issuer of
the complete CRL. The trust anchor for the certification
path MUST be the same as the trust anchor used to validate
the target certificate.

It will take some care to be able to meet this requirement outside the context of building and verifying the path used to validate an end entity certificate.

However, since signature validation is expensive and CRLs are loaded infrequently but consulted for revoked certificates frequently it would be a nice optimization if we could perform signature validation once-up front instead of per-access.

Lingua principale
Rust
Stelle
167
Fork
112
Merge medio
4h 28m
PR unite (30g)
4

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di rustls/webpki

Tutte le issue di rustls/webpki

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.