Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Various Mapserver Performance Optimizations #31

Open
cyrill-k opened this issue Jan 30, 2023 · 0 comments
Open

Various Mapserver Performance Optimizations #31

cyrill-k opened this issue Jan 30, 2023 · 0 comments

Comments

@cyrill-k
Copy link
Collaborator

cyrill-k commented Jan 30, 2023

Here, we list various performance improvements for the updating and fetching operations of the mapserver in legacy and policy mode.

Updating

  • Redesign DB for faster insertion speed
  • Store certificate hashes instead of certificates
  • Homomorphic hashing (unsure if it works, could use expiration times, SCT timestamps, serial numbers+CA)

Fetching (processing)

  • Weighted retrieval (cache, flatten certain records only)

Fetching (payload, legacy)

  • Prune expired certificates from mapserver
  • Omit data from or reduce size of payloads
    • Allow client to only fetch references (i.e., hashes of leaf certificates)
    • Omit root certificates since they must be known by the client
    • Omit certain (well-known) intermediate certificates
  • Send trust preferences to the mapserver
    • Homomorphic encryption to mitigate privacy issues
    • Connection establishment to mapserver occurs potentially over 3 RTTs later
    • Get quorum of multiple mapservers to improve security
  • Cache on client side (done in firefox plugin)
  • Shorten proof length (unclear how much benefits this would bring)
  • Split entries into 2 trees covering different domains (fast class + slow class), split requests with proxy to the respective tree
  • Store (sorted or sparse) Merkle trees mapping (P)CAs to corresponding certificate sets in each leaf entry of a mapserver
  • Employ bloom filters on the mapserver (unclear how this would work in detail)
  • Apply revocations to existing certificates, don't send to client any revocation or revoked certificate. The revocations must stay in DB, because new certificates would come up that would be revoked by those revocations; but at an instantaneous moment, the responder can derive which certificates should not be present anymore. Or maybe this should be done at ingest time?

Fetching (payload, policy)

  • Proof size could become problematic as it can grow to arbitrarily large (many PCAs and long policies)
  • Send trust preferences to the mapserver and only return decision with or without the actually used policies.
    • Apply revocations to existing PCs and RPCs, don't send to client any revocation or revoked material.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant