Rather than storing full x509.Certificates in the root pool we could instead store only the information that we require to accomplish chain building (SPKI, subject, name constraints), significantly reducing the memory footprint for the pool.
When returning certificate chains from Verify we'd need to construct a stand-in x509.Certificate which is only partially populated (we'd need to decide what fields to set, and what we can get away with setting based on a typical root profile, i.e. is it safe to consistently set the issuer to match the subject, even for roots where the issuer does not actually match?). Depending on what users are doing with certificates it is possible that this could break some things. As such we should try to land this change early in the 1.17 cycle so any significant breakages are signaled early.
This would also reduce binary sizes on iOS where we bundle roots, and also make things like #43958 somewhat more appealing from a binary bloat perspective.
Rather than storing full
x509.Certificates in the root pool we could instead store only the information that we require to accomplish chain building (SPKI, subject, name constraints), significantly reducing the memory footprint for the pool.When returning certificate chains from Verify we'd need to construct a stand-in
x509.Certificatewhich is only partially populated (we'd need to decide what fields to set, and what we can get away with setting based on a typical root profile, i.e. is it safe to consistently set the issuer to match the subject, even for roots where the issuer does not actually match?). Depending on what users are doing with certificates it is possible that this could break some things. As such we should try to land this change early in the 1.17 cycle so any significant breakages are signaled early.This would also reduce binary sizes on iOS where we bundle roots, and also make things like #43958 somewhat more appealing from a binary bloat perspective.