David Benjamin

> ([draft-celi-acvp-symmetric 7.3-25](https://pages.nist.gov/ACVP/draft-celi-acvp-symmetric.html#section-7.3-25)) for their AES FF1 testcases which is at least some small evidence that might be a viable route. Hmm. That seems unable to represent anything above radix...

I was envisioning a YOLO interface just to not have to make so, so many functions, but not opposed to validating one(s). If it's validating, separate functions feels better, but...

> I definitely advocated not to derive the public key automatically on-demand from the private key during operations that required the public part, as that could be weaponized to trigger...

Ah yeah, OpenSSL's release cycle makes it hard to reliably add the new thing before removing the old thing. Planning for such things happens too infrequently and too late. The...

Ah yeah, my comment above was specifically about who would need ifdefs for `flags` APIs that don't yet exist. Whether or not you opaquify it now, those should be added...

> I'm happy to help clean that out by sending projects patches, once we've established the preferred APIs. For that matter, since `type`, `data`, and `length` APIs already exist, I...

Yeah, for better or worse, the fact that `ASN1_INTEGER` is the same type as `ASN1_STRING` is thoroughly exposed in the public API.

I assume it was less a conscious choice and more that it compiled, so no one noticed. (Curl seems to actually set a pretty high minimum now. https://github.com/curl/curl/pull/18330 and https://github.com/curl/curl/pull/18822)

@botovq Wowwww, thanks for going through all that!

Ah, interesting. In retrospect, that makes some sense. Outside the library, there's much less use in replacing an `ASN1_STRING` in-place. You can probably just make a new one. (`X509_set1_notBefore` vs...