Key assurance really depends on what you are doing, so I don't think this is quite true. For example if you generate a key using a valid algorithm (that is validated by a lab), then there is already an assurance that the key is valid without needing to run EVP_PKEY_check().
There are many operations that don't need EVP_PKEY_check, but they may need a sub check such as EVP_PKEY_public_check, EVP_PKEY_param_check, EVP_PKEY_private_check or EVP_PKEY_pairwise_check (or some combination of those). Keys (and certs) that are received from another entity should be validated unless there is some other mechanism for establishing that the key is trusted. > On 12 Nov 2020, at 12:14 am, Nicola Tuveri <nic....@gmail.com> wrote: > > In light of recently working more closely to `EVP_PKEY_check()` I > would add to the discussion on this vote that it is not entirely true > that we were not enforcing the keypair assumption and that the current > strict behavior of the EC keymgmt in 3.0 is a breaking change w.r.t. > some uses that work in 1.1.1. > > In particular in 1.1.1, the key created as depicted in #12612 that > triggered this discussion (Matt posted a useful reproducer among the > first comments), is indeed capable of signing in the used pattern, but > the pattern is conveniently omitting the validation pass that should > be required in any serious use of the API. > > `EVP_PKEY_check()` > (https://urldefense.com/v3/__https://www.openssl.org/docs/man1.1.1/man3/EVP_PKEY_check.html__;!!GqivPVa7Brio!PdWuiQz52CFt9zZk9s6He6IimqtSPbLrvJ1ck_RKJIydCE80FY4lRl-WD8v1m4r6Zg$ > ) is > one of the many places in 1.1.1 where both the documentation and the > behavior assume that an `EVP_PKEY` object is a keypair. > Even in the version used by the user that posted the issue, running > `EVP_PKEY_check()` on the created key would have revealed that the > user was abusing the API. > > The "lack of enforcement" argument, that was partially at the base of > formulating the vote text as it is, and conditioned our votes, seems > to me an intentional design choice, as part of preferring the usage > pattern "validate once, and reuse many times": for performance reasons > we are not running `EVP_PKEY_check()` on every single key loaded from > a PEM file or created by the user, but there is an assumption that the > user did validate at least once the key material using > `EVP_PKEY_check()` or `openssl pkey -check`. > So enforcement was never lacking, but it was relegated together with > more expensive checks, into functions that the user should execute at > least once, possibly according to well documented security policies > concerning the management of key material in transit and at rest. > > Omitting the `EVP_PKEY_check()` in the reproducer and the user > application, would for example allow me to write a DoS attack: the > secret scalar could easily be hand-picked to trigger an endless loop > in the sign operation. > > > -- > > Nicola > > > > On Tue, Nov 3, 2020 at 2:11 PM Matt Caswell <m...@openssl.org> wrote: >> >> Background to the vote: >> >> The OTC meeting today discussed the problems raised by issue #12612. In >> summary the problem is that there has been a long standing, widespread >> and documented assumption that an EVP_PKEY with a private key will >> always also have the public key component. >> >> In spite of this it turns out that in the EC implementation in 1.1.1 it >> was perfectly possible to create an EVP_PKEY with only a private key and >> no public key - and it was also possible to use such an EVP_PKEY in a >> signing operation. >> >> The current 3.0 code in master introduced an explicit check (in line >> with the long held assumption) that the public key was present and >> rejected keys where this was not the case. This caused a backwards >> compatibility break for some users (as discussed at length in #12612). >> >> The OTC discussed a proposal that we should relax our conceptual model >> in this regards and conceptually allow EVP_PKEYs to exist that only have >> the private component without the public component - although individual >> algorithm implementations may still require both. >> >> It is possible to automatically generate the public component from the >> private for many algorithms, although this may come at a performance and >> (potentially) a security cost. >> >> The proposal discussed was that while relaxing the conceptual model, >> most of the existing implementations would still require both. The EC >> implementation would be relaxed however. This essentially gives largely >> compatible behaviour between 1.1.1 and 3.0. >> >> The vote text is as follows: >> >> topic: For 3.0 EVP_PKEY keys, the OTC accepts the following resolution: >> * relax the conceptual model to allow private keys to exist without public >> components; >> * all implementations apart from EC require the public component to be >> present; >> * relax implementation for EC key management to allow private keys that >> do not >> contain public keys and >> * our decoders unconditionally generate the public key (where possible). >> >> Proposed by Matt Caswell >> Public: yes >> opened: 2020-11-03 >> closed: 2020-mm-dd >> accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) >> >> Matt [+1] >> Mark [ ] >> Pauli [+1] >> Viktor [ ] >> Tim [ ] >> Richard [+1] >> Shane [+1] >> Tomas [+1] >> Kurt [ ] >> Matthias [ ] >> Nicola [-1]
