<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'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'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'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.</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'm not certain, but I think keybase might be getting this wrong too.</div><div><br></div><div>-Shannon</div></div>