Discussion: Roadmap and future

Hi,

I am reaching out to you as a member of the Red Hat Crypto team. We are evaluating upki as the foundation for system-wide certificate verification on fedora/rhel/centos, targeting parity with Mozilla Firefox's certificate validation behavior. We find the project direction very compelling and the roadmap items align well with what we need.

As part of this effort we are planning integrations with GnuTLS, OpenSSL, NSS, and potentially
other crypto libraries — so we expect to be working closely with the C FFI and OpenSSL callbackpaths in particular. We have already opened a discussion with the OpenSSL project on this topic https://github.com/openssl/openssl/discussions/31932. We wanted to open a discussion about a few areas we could not find on the current roadmap or in open issues, and ask where you are heading with them.

1. NotCoveredByRevocationData and the fresh-certificate grace period

Firefox exempts certificates issued within the last 10 days from revocation checks. upki returns
NotCoveredByRevocationData for certificates outside the filter window, which is in the same
ballpark but not the same policy. Is there a plan to expose a certificate-age threshold in the
Policy / Outcome API to match this behaviour?

2. CT policy: multiple SCTs from distinct log operators

We presume CT enforcement is on the roadmap, and as part of that — Firefox's CT policy requires
SCTs from a minimum number of independently operated logs, not just the presence of any SCT. The
The current Policy API only distinguishes "has at least one SCT" from "has none." Is a configurable
threshold and log list management something you intend to cover as part of that work?

3. OneCRL

Mozilla's OneCRL covers emergency revocation of intermediate CAs outside of the normal CRLite
flow. Is integrating something equivalent on your roadmap, or is this considered out of scope?

4. Alternate path building with a cached intermediate store

Currently path building is delegated to rustls-webpki, which builds a single path from the chain
provided by the caller. Retry against a cached intermediate store would be particularly valuable
during root transitions. Is this planned as part of the intermediate preloading work, or considered
out of scope?

Start by reading the current roadmap and open issues, then inspect the Policy/Outcome API and the rustls-webpki path-building boundary described here. Done would be a maintainer decision on the four requested areas and a clear roadmap or scope statement, rather than a standalone code change.