So it looks like there are bunch of test that expect to not have public keys available when just the private key is imported.

Is there any reason for this?

You can see that some tests are failing because it was expected to fail.
I cant recall the history, but I am hoping an ex OTC member such as @romen or @levitte might recall.
(Maybe auto loading the public key when only the private key was needed was undesirable?)

If I remember correctly, it was because of perfomance reasons, probably DNSSec related

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 a scalar multiplication remotely to exploit the non-const-time bignum (and sometime EC, depending on the backend implementation).

This PR derives it in on _fromdata(), which normally should happen only on load, so mine shouldn't be a concern in this case.
But I'd like an expert confirmation that _fromdata() is not itself autotriggered during the execution of operations, in some weird scenario!

So should I simply remove offending tests? Or try to make sure they do not use _fromdata() and preserve some of them? something else?

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 a scalar multiplication remotely to exploit the non-cont-time bignum (and sometime EC, depending on the backend implementation).

Scalar multiplication is also the operation one performs for EC operations in the first place. If that's leaky, what hope do you have to of using the key under this threat model in the first place?

(I have not checked whether it's always constant-time or not in OpenSSL, but I don't see how deriving the public key has any impact here.)

@simo5 I think yes, try to make sure that they don't use _fromdata and preserve as much as possible

@openssl/committers need a second pair of eyes here

If I remember correctly, it was because of perfomance reasons, probably DNSSec related

Why would specifically DNSSEC deployments be averse to deriving the public key from the private key? In BIND, both parts of the key are pregenerated, and stored in custom internal formats (32 byte raw exponent and 64-byte uncompressed public point):

$ dnssec-keygen -K . -a ECDSAP256SHA256 acme.example
Generating key pair.
Kacme.example.+013+54234

$ cat Kacme.example.+013+54234.private 
Private-key-format: v1.3
Algorithm: 13 (ECDSAP256SHA256)
PrivateKey: aNFCp7VhAKUgsfRmKy7RGZb77wtuwID0281Lq0k7KZ0=
Created: 20251213011140
Publish: 20251213011140
Activate: 20251213011140

$ awk '/PrivateKey:/{print $2}' Kacme.example.+013+54234.private  |
    openssl base64 -d |
    xxd -c32 -p
68d142a7b56100a520b1f4662b2ed11996fbef0b6ec080f4dbcd4bab493b299d

$ cat Kacme.example.+013+54234.key 
; This is a zone-signing key, keyid 54234, for acme.example.
; Created: 20251213011140 (Sat Dec 13 12:11:40 2025)
; Publish: 20251213011140 (Sat Dec 13 12:11:40 2025)
; Activate: 20251213011140 (Sat Dec 13 12:11:40 2025)
acme.example. IN DNSKEY 256 3 13 D5c3Lj5KrTBAFHhsfY2WuZl5TZVMbyH9131eThs2cw4BWKMs1fgJeZFA UD4jmmrZDFxpz1SYUbXRmjLStO3tfA==

$ awk '/DNSKEY/{print $7 $8}' Kacme.example.+013+54234.key  |
    openssl base64 -A -d |
    xxd -p -c32
0f97372e3e4aad304014786c7d8d96b999794d954c6f21fdd77d5e4e1b36730e
0158a32cd5f809799140503e239a6ad90c5c69cf549851b5d19a32d2b4eded7c

The signer can choose to import both parts of the key or just the private key, though the keyid (54234) is then based only on the file name, rather than computed from the public key checksum.

The scenario that comes to mind is some system that hosts a very large number of zones, preloading all their private keys into memory on startup, loading only the private components.
The public component is available, and where computing the public points would be a significant startup cost. Any such systems can import both parts of the key (both are known), but perhaps they don't expect to have to do that???

I am not convinced that's a compelling use-case.

24 hours has passed since 'approval: done' was set, but as this PR has been updated in that time the label 'approval: ready to merge' is not being automatically set. Please review the updates and set the label manually.

Merged to the master branch. Thank you for your contribution.