Re: OTC VOTE: EVP_PKEY private/public key components

2020-11-11 Thread Nicola Tuveri
Usually the labs provide assurances on the key generation and the other cryptographic operations, including validation, but have special provisions to avoid providing assurances on key serialization and deserialization. This seems particularly true in the context of the FIPS validation for

Vote results: remove -crypt option from passwd and C source output options

2020-11-11 Thread Dr Paul Dale
Vote: Drop from 3.0 support for the '-crypt' option from the passwd application For: 6, Against: 0, Abstain: 0, Didn’t vote: 1 The vote passes. Vote: Drop from 3.0 support for the C code output options from the applications where the use of deprecated APIs is required For: 4, Against: 0,

Re: OTC VOTE: EVP_PKEY private/public key components

2020-11-11 Thread SHANE LONTIS
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

Re: OTC VOTE: EVP_PKEY private/public key components

2020-11-11 Thread Nicola Tuveri
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

Re: [OTC VOTE PROPOSAL] Approve behavior change for `pkey -[pub]check`

2020-11-11 Thread Nicola Tuveri
I could see reasons to vote negatively for such a resolution in generic terms if I was voting on it: often the OpenSSL apps are part of critical PKI procedures and scripts. Such scripts might very well rely on the fact that this or that openssl command does not return a failure exit status in

Re: [OTC VOTE PROPOSAL] Approve behavior change for `pkey -[pub]check`

2020-11-11 Thread Tomas Mraz
Yep, frankly the current behavior of the app in regards to failing -check/-pubcheck does not make that much sense and really looks more like a bug than anything else. If the user does not care about the failure of the check and want to proceed with other actions, nothing stops them from just not

Re: [OTC VOTE PROPOSAL] Approve behavior change for `pkey -[pub]check`

2020-11-11 Thread Dr Paul Dale
An OMC vote deeming that adding error checks like this are or are not considered breaking changes. My view is that detecting an error condition and returning an error code is a bug fix rather than a breaking change. Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations

Re: [OTC VOTE PROPOSAL] Approve behavior change for `pkey -[pub]check`

2020-11-11 Thread Nicola Tuveri
That is a very good point I completely missed! Would you be available do "adopt" my vote and raise it as an OMC vote? Nicola On Wed, Nov 11, 2020, 11:10 Matt Caswell wrote: > I have no problem with the proposal or the vote text. I only wonder > whether, as a breaking change an OMC vote is

Re: [OTC VOTE PROPOSAL] Approve behavior change for `pkey -[pub]check`

2020-11-11 Thread Matt Caswell
I have no problem with the proposal or the vote text. I only wonder whether, as a breaking change an OMC vote is required? Or is an OTC vote sufficient? Matt On 10/11/2020 16:15, Nicola Tuveri wrote: > ## Background > > As part of the discussion in [issue #8435], it was highlighted that both