Vote: Automatically compute public key on import if missing

[t8m]

Topic: For all currently implemented algorithms, where it is possible,
       if the public key component is missing when a key is imported
       into a provider, the public key component should be computed.
Proposed by: Tomas Mraz
Issue link:.
Public: yes
Opened: 2022-09-06
Closed:.
Accepted:  yes/no  (for: , against: , abstained: , not voted: )

  Dmitry     [ 0]
  Matt       [  ]
  Pauli      [+1]
  Tim        [  ]
  Richard    [ 0]
  Shane      [+1]
  Tomas      [ 0]
  Kurt       [  ]
  Matthias   [+1]
  Nicola     [+1]

[t-j-h]

Vote: -0

[kroeckx]

Some background information would be nice. Is there some other issue with more information?

Does this apply to just master, or also 3.0?

What is the expected cost of this?

[paulidale]

The comment that triggered this was: https://github.com/openssl/openssl/pull/19105#discussion_r961900017 Followed by @slontis nothing that we do this for ECX already.

In my mind this is an issue of consistency. We do this in all scenarios bar one, that's bad API design.

I don't think we'd touch 3.0 here, although I personally consider this to be an API bug.

[kroeckx]

We already have a vote that was accepted that says: "our decoders unconditionally generate the public key (where possible)." How is this different? Does this say it's not only for our providers, but for all providers?

[levitte]

We already have a vote that was accepted that says: "our decoders unconditionally generate the public key (where possible)." How is this different?

It moves the solution to the problem to a different place, basically. Instead of being something for a DECODER to deal with, it becomes something for a KEYMGMT to deal with.

Also, I assume that this is still something for our implementations, not something we can force on all providers out there. (which implies that libcrypto code might still need some fixes to handle diverse unknowns)

[mattcaswell]

We previously held a vote that said the opposite:

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).

I seem to recall there was some significant debate over this topic, and a specific corner case that triggered it. Do we know what the original issue was that caused us to make that decision?

I am hesitant to change something that we only recently decided to do in 3.0. OTOH, I see the benefits of this.

Vote: 0

[levitte]

We previously held a vote that said the opposite:

Well, kinda sorta... I'd say that this part from that vote is more inline with this vote than it's opposing it:

* all implementations apart from EC require the public component to be present;

[kroeckx]

We had a vote that passed that said:

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).

Followed by an other vote that passed:

topic: For 3.0 EVP_PKEY keys all algorithm implementations that were usable
       with 1.1.1 EVP_PKEY API or low level APIs without public component must
       stay usable.

       This overrules the
         * all implementations apart from EC require the public component to be present;
       part of the vote closed on 2020-11-17.

As far as I remember, it was some DNS implementation that only loads the private key.

[kroeckx]

So I'm still not sure what the difference is between the previous votes and the current vote

[t8m]

It does not fully contradict either of the previous votes. It just says that we will unconditionally compute the public part if it is missing and it is possible on import to the provider (not just in decoders).

[kroeckx]

As in, it happens now in the decoders, but if someone directly passes it to a provider without using our decoders it doesn't happen?

[t8m]

Yes, and inconsistently so between dh, ecdh and ecx dh. The ecx keys will automatically compute the public key but the other two key types not.

[kroeckx]

So I'm going to vote +1 for this.

But it's currently not clear to me how this affects the other points of the previous 2 votes related to this. Can EC always generate a public key from the private key, and so the public key is now always present?

[levitte]

Can EC always generate a public key from the private key

As far as I understand, yes.

and so the public key is now always present?

I think that's a matter of implementation... an implementation could say that it's always available, and produce it on demand when actually needed (hopefully, that implementation is smart enough to cache the result).

[t8m]

Vote is closed.

Topic: For all currently implemented algorithms, where it is possible,
       if the public key component is missing when a key is imported
       into a provider, the public key component should be computed.
Proposed by: Tomas Mraz
Issue link:.
Public: yes
Opened: 2022-09-06
Closed: 2022-09-21
Accepted:  yes  (for: 5, against: 0, abstained: 5, not voted: 0)

  Dmitry     [ 0]
  Matt       [ 0]
  Pauli      [+1]
  Tim        [-0]
  Richard    [ 0]
  Shane      [+1]
  Tomas      [ 0]
  Kurt       [+1]
  Matthias   [+1]
  Nicola     [+1]