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