<div dir="ltr">Hi,<br><div><br></div><div>When reaching out to the BouncyCastle community regarding the deprecated javax.security.cert APIs, I got some interesting feedback from Matti Aarnio of Methics Ltd:</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Long ago we did encounter problems with JRE's X509CertImpl.java  class, and more so with X509CRLImpl.java. Both have internal caches of binary form input that is then converted to parsed forms.</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Especially the CRL cache did not (still does not?) have nice "that version is obsoleted, drop it to garbage collection" handling of parsed CRLs, while it had way too large cache size.<br>A server running for months and getting a new CRL every 12 hours eventually grew the memory footprint of obsolete parsed data up to ridiculous amounts of gigabytes of heap footprint.</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Once we realized that also certificate parser had such a cache and that there is no official way to control that cache, we became very much averse of using those APIs. </blockquote><div> </div><div>It seems the lack of cache control of these static implementation caches can be problematic, especially in the CRL case. The default for both caches is a max number of entries of 750 with an unlimited lifetime. The inability of expiring outdated CRLs seems particularly problematic for Matti.</div><div><br></div><div>A similar issue was reported in JDK-8059007 back in 2014, with the following comment from Sean:</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">We need to introduce some system properties (or something similar) to allow the crl/cert caches to be adjusted. Changing to RFE.</blockquote><div><br></div><div>While it would certainly be nice to add some form of cache control, the solution space is large:</div><div><br></div><div>-1: Remove the cache. One could claim that the parser/factory level is the wrong level to introduce parsing. There are so many ways to tune parsing, there exists many excellent libraries. If apps need caching, they should take care of it at the app level.</div><div><br></div><div>0: Do nothing, there haven't been that many complaints</div><div><br></div><div>1: Add an option to entirely disable the cache such that apps can do their own caching (or not) without wasting space in the default cache.</div><div><br></div><div>2: Add two system properties to control max entries of the cert and crl cache. Setting these to 0 would disable the cache.</div><div><br></div><div>3: Add four system properties to control max entries and max lifetime for each of the cert and crl caches. Setting max entries to 0 would disable a cache.</div><div><br></div><div>4: Tune the default max entries and lifetime to make everyone happy.</div><div><br></div><div>5: Add a pluggable API to control caching. Think AbstractCacheControllingMaxEntrySizeProxyFactoryContext :-)</div><div><br></div><div>6: Something I did not consider.</div><div><br></div><div>-1 is probably not desired/possible because of the behavioural change. 1 is simple but very constrained. 2 and 3 are similar in shape where 3 allows more flexibility introducing lifetime. 4 seems like wishful thinking. You could probably guess I'm not a big fan of 5. 6 seems promising :-)</div><div><br></div><div>I have a sketch implementation of 3 available, but it would be great to gather some opinions before I put more work into this:</div><div><br></div><div><a href="https://github.com/openjdk/jdk/compare/master...eirbjo:jdk:x509factory-cache-config">https://github.com/openjdk/jdk/compare/master...eirbjo:jdk:x509factory-cache-config</a><br></div><div><br></div><div>Thanks,</div><div>Eirik.</div><div><br></div><div>[1] <a href="https://bugs.openjdk.org/browse/JDK-8059007" target="_blank">https://bugs.openjdk.org/browse/JDK-8059007</a></div><div><br></div><div> </div><div><br></div><div><br></div><div> </div></div>