[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gnupg-users
Subject:    Re: GnuPG public key vulnerability?
From:       Shannon C <rehevkor5 () gmail ! com>
Date:       2017-11-02 17:56:21
Message-ID: CAHiwhzJgOUJdPqm1AjLmoHCHUz+vCOZQ4sXz6FsPsWHFHXk+hA () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


>
> so at Facebook, we checked
> the public keys that have been uploaded to people's profiles, and notified
> people whose keys are affected


 Jon,

FYI your detection logic seems a bit overzealous, because (last time I
checked) it detects revoked ROCA-vulnerable subkeys as making the whole
public key unacceptable, even if the private key is not affected by ROCA.
According to the responses on this thread
https://lists.gnupg.org/pipermail/gnupg-users/2017-October/059417.html
ROCA-affected subkeys have no effect on the validity of the private key or
other subkeys, so if they're revoked everything should be ok.

Rejecting public keys in this way is problematic for two reasons I can
think of:
1. It confuses people because it implies that there's something wrong with
your whole key even though the problem is only with a subkey. And it
implies that revoking the subkey doesn't solve the problem.
2. It will force people to do extra work to remove their subkeys before
exporting their public key for upload to Facebook. This is annoying to do
and might lead to people deleting their subkeys from their local keyring
permanently, which is probably a bad idea.

I'm not certain, but I think keybase might be getting this wrong too.

-Shannon

[Attachment #5 (text/html)]

<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span \
style="font-size:12.8px">so at Facebook, we checked</span><br \
style="font-size:12.8px"><span style="font-size:12.8px">the public keys that have \
been uploaded to people&#39;s profiles, and notified</span><br \
style="font-size:12.8px"><span style="font-size:12.8px">people whose keys are \
affected</span></blockquote><div><br></div><div>  Jon,</div><div><br></div><div>FYI \
your detection logic seems a bit overzealous, because (last time I checked) it \
detects revoked ROCA-vulnerable subkeys as making the whole public key unacceptable, \
even if the private key is not affected by ROCA. According to the responses on this \
thread  <a href="https://lists.gnupg.org/pipermail/gnupg-users/2017-October/059417.html">https://lists.gnupg.org/pipermail/gnupg-users/2017-October/059417.html</a> \
ROCA-affected subkeys have no effect on the validity of the private key or other \
subkeys, so if they&#39;re revoked everything should be \
ok.</div><div><br></div><div>Rejecting public keys in this way is problematic for two \
reasons I can think of:</div><div>1. It confuses people because it implies that \
there&#39;s something wrong with your whole key even though the problem is only with \
a subkey. And it implies that revoking the subkey doesn&#39;t solve the \
problem.</div><div>2. It will force people to do extra work to remove their subkeys \
before exporting their public key for upload to Facebook. This is annoying to do and \
might lead to people deleting their subkeys from their local keyring permanently, \
which is probably a bad idea.</div><div><br></div><div>I&#39;m not certain, but I \
think keybase might be getting this wrong \
too.</div><div><br></div><div>-Shannon</div></div>



_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


[prev in list] [next in list] [prev in thread] [next in thread]