<div dir="ltr"><div>On Wed, Oct 7, 2020 at 8:29 PM Kurt Roeckx <<a href="mailto:kurt@roeckx.be">kurt@roeckx.be</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, Oct 07, 2020 at 12:29:10PM +0100, Matt Caswell wrote:<br>
> Issue #12612 exposes a problem with how we handle keys that contain<br>
> private components but not public components.<br>
> <br>
> There is a widespread assumption in the code that keys with private<br>
> components must have public components. There is text in our public<br>
> documentation that states this (and that text dates back to 2006).<br>
> <br>
> OTOH, the code has not always enforced this. Issue #12612 describes a<br>
> scenario where this has not historically been enforced, and it now is in<br>
> the current 3.0 code causing a regression.<br>
> <br>
> There are differences of opinion on how this should be handled. Some<br>
> have the opinion that we should change the model so that we explicitly<br>
> allow private keys to exists without the public components. Others feel<br>
> that we should continue with the old model.<br>
<br>
It seems to me that we have various ways forward:<br>
1) Enforce that a private key requires the public key<br>
2) Don't enforce it, just give an error when you try to use the<br>
   public key and it's not available.<br>
3) Make it work for the same cases that worked with 1.1.1<br>
4) Generate the public key from the private key<br>
5) Have some kind of transition where we do 2), 3)<br>
   or 4) in 3.0, but will move to 1) at some later point.<br>
6) do 2), but enforce it in the fips provider<br>
<br>
I don't know if we do any any kind of consistency checks on the key<br>
now when it's loaded. But 2) would then imply that the check is<br>
skipped instead of returning an error.<br></blockquote><div><br>4) maybe not applicable when a private key is on the hardware token. </div></div><div><br></div>-- <br><div dir="ltr" class="gmail_signature">SY, Dmitry Belyavsky</div></div>