Re: [Sks-devel] SKS should not accept or replay non-exportable certifications

[Daniel Kahn Gillmor]

Wow, this has really gotten on the wrong foot.  Sorry about that; let me
try to get it back on track.

John, i'm sorry that i made the example non-exportable signature on your
key.  That was a dumb thing for me to do; I clearly should have made the
demonstration on another example key.  I screwed up, and i offer my
apologies.

Let me also be clearer about why i find this bug serious and hope we can
figure out how to get it fixed: I have told numerous people that the
keyserver network will not propagate local signatures.  I have written
and deployed software that makes regular use of both local signatures
and the keyserver network, while expecting that any error (in my own
code, in the code that my code depends on, or operator error) that
causes these local signatures to leak out would at least be somewhat
mitigated by the keyservers' general policy of not propagating local
signature.  If the keyserver network actively forwards these
certifications, then users of the keyserver network and local
certifications stand a greater risk of global data leakage that they do
not want.

Clearly, i was mistaken in assuming the keyservers were implemented this
way.  But i still believe this to be a reasonable expectation, and hope
that Phil's proposal of a filter that would filter any new
non-exportable signatures from propagation could be deployable.

I've made a patch and a pull request on bitbucket.  I've tested the
patch and it does effectively discard certifications marked as
non-exportable:

 
https://bitbucket.org/skskeyserver/sks-keyserver/pull-request/20/trim-local-certifications-from-any-handled/diff

I know very little ocaml (this is my first ocaml patch ever, i think),
so i would greatly appreciate whatever guidance you can give me on how
to improve it.

On Fri 2013-09-13 19:51:33 -0400, John Clizbe wrote:

> Note -- honoring the not-exportable flag on a self-sig breaks the
> standard in IMO a worse way, UID(s) without binding sig(s).

I agree that it's a problem if we have SKS propagating keys with User
IDs that aren't properly bound with a self-sig.  The current
implementation already does this (see the example here [0], which has no
self-sig at all) -- and SKS even imports and propagates raw public keys
that have no UID whatsoever, which seems troubling.  I'm happy to try to
offer patches to fix these problems as well.

Can you let me know if the pull request above is headed in the right
direction?

Regards,

        --dkg

[0] 
https://keys.mayfirst.org/pks/lookup?op=vindex&search=a+test+of+a+bogus+key&fingerprint=on

pgppSh3B5evo3.pgp
Description: PGP signature