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

Abierto
  • ¿Algo no está bien?
#81 1 comentario 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
38/100
Tipo de issue
Refactorización
Claridad
Bastante claro
Estado de actividad
Estancado
Stack tecnológico
rust
Área
cryptography, security

Línea de trabajo

Comienza con el manejo de CRL en el pull request de referencia y en src/verify_cert.rs alrededor de las líneas 219-222; después, revisa RFC 5280 §6.3.3. Se considera terminado cuando la validación de la firma de CRL se realiza una vez durante la carga o la preparación, en lugar de hacerlo en cada comprobación de revocación, preservando al mismo tiempo la relación requerida con el trust-anchor.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
Rust
Estrellas
167
Forks
112
Merge medio
4 h 28 min
PR fusionados (30 d)
4

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de rustls/webpki

Todos los issues de rustls/webpki

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.