topic: In 3.0 it will not be possible to use SM2 with a non-SM2 curve. This
should be documented.
Proposed by Matt Caswell
Public: yes
opened: 2021-03-09
closed: 2021-mm-dd
accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T)
Matt [+1]
Mark [ ]
Pauli
topic: EVP init functions take an OSSL_PARAM array to set parameters and
this
should be reflected in the equivalent provider interface.
Proposed by Matt Caswell
Public: yes
opened: 2021-03-09
closed: 2021-03-09
accepted: yes (for: 5, against: 0, abstained: 2, not voted: 4)
Matt
For OTC members - please note that this vote is not closed, so your
vote counts if you have not voted yet! :D
On Tue, 2021-03-09 at 10:24 +, Matt Caswell wrote:
> topic: In 3.0 it will not be possible to use SM2 with a non-SM2
> curve. This
> should be documented.
> Proposed by Matt
It is tangent to the vote in itself, but I'd like to highlight that in part
this vote is motivated by getting rid of cases where there is a need to
convert between compatible key types (e.g. SM2 & EC, DH & DHX).
The vote of this text does not cover it, but another use case that we will
likely
This is related to the discussion in PR #14383. It has already been
decided to add OSSL_PARAM arrays as an argument to the various EVP
"init" functions. During the implementation of that there were differing
views about whether this same change should be reflected in the
core<->provider
On Tue, Mar 09, 2021 at 10:25:50AM +, Matt Caswell wrote:
> topic: EVP init functions take an OSSL_PARAM array to set parameters and
> this
>should be reflected in the equivalent provider interface.
+1
Kurt
On Tue, Mar 09, 2021 at 10:25:50AM +, Matt Caswell wrote:
> topic: EVP init functions take an OSSL_PARAM array to set parameters and
> this
>should be reflected in the equivalent provider interface.
I need more information than the vote text to be able to vote on
this.
Kurt
On Tue, Mar 09, 2021 at 03:57:32PM +0200, Nicola Tuveri wrote:
> It is tangent to the vote in itself, but I'd like to highlight that in part
> this vote is motivated by getting rid of cases where there is a need to
> convert between compatible key types (e.g. SM2 & EC, DH & DHX).
>
> The vote of
Yes, in 1.1.1j the following is possible:
- SM2 cryptosystem operations over the "SM2 curve"
- SM2 cryptosystem operations over arbitrary curve (including NIST ones)
- ECDSA/ECDH cryptosystem operations over the "SM2 curve"
(See attached patches to verify this is the case in the tests)
They
