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

Open
  • Is something wrong?
#81 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
38/100
Issue type
Refactor
Clarity
Mostly clear
Activity status
Stale
Tech stack
rust
Domain
cryptography, security

Research direction

Start with the CRL handling in the referenced pull request and src/verify_cert.rs around lines 219-222, then review RFC 5280 §6.3.3. Done means CRL signature validation occurs once during loading or preparation rather than on every revocation check, while preserving the required trust-anchor relationship.

Written by the indexing model from the issue text.

Description

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.

Dominant language
Rust
Stars
167
Forks
112
Avg merge
4h 28m
Merged PRs (30d)
4

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from rustls/webpki

All issues in rustls/webpki

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.