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

[Jason Harris]

On Sat, Sep 14, 2013 at 05:00:28PM -0400, Robert J. Hansen wrote:
> On 9/14/2013 3:08 PM, Daniel Kahn Gillmor wrote:

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

Correct.  I specifically use --lsign-key on keys I've carefully
checked and keyrings I copy around in binary (and under revision
control).  Since GPG doesn't normally export non-exportable sigs:

  lsign  Same as "sign"  but  the  signature  is  marked  as  non-
         exportable  and  will  therefore never be used by others.
         This may be used to make keys valid  only  in  the  local
         environment.

but can be [mis]configured to send/receive them to/from keyservers
with:

  --keyserver-options export-local-sigs import-local-sigs

or, far more likely with:

  export-options export-local-sigs
    Allow exporting key signatures marked as "local". This is
    not generally useful unless a shared  keyring  scheme  is
    being used.  Defaults to no.

  import-options import-local-sigs
    Allow importing key signatures marked as "local". This is
    not generally useful unless a shared  keyring  scheme  is
    being used.  Defaults to no.

permanently set in gpg.conf - for users who also employ lsign and
manage their keyrings manually.

Such users would ALWAYS UNWITTINGLY LEAK these signatures via manual
copy/paste, which is still quite useful for publishing keys on
webpages, for example.

In fact, it seems that I still have:

  import-options import-unusable-sigs import-local-sigs
  export-options export-unusable-sigs export-local-sigs

and even a very old repair-hkp-subkey-bug lurking in my gpg.conf.

So, especially in light of my [mis]configuration, I would prefer that
keyservers DO NOT leak what "will therefore never be used by others."

> Please show me real users who are having troubles dealing with this bug.

I have a current SKS keydump, but I don't know if pgpring (see
older mutt tarballs) decodes/reports that flag.  It seems that
pgpdump 0.28, which does, can't fully process the files:

  %pgpdump sks-dump-0025.pgp | grep -c "Public Key Packet"
  pgpdump: unknown compress algorithm.
  12360

(of ~15,000 keys each)...

>  Not just you, because we've already established you're in love with
> weird corner cases.  If this is affecting real users then I would be all
> in favor of further discussion on this subject.  Without them, though,
> I'm inclined to say "enough already!"

...so, without data, we can't be sure if this is, indeed, one of
those "weird corner cases."

> decision is, then there is no wrong decision.  Move forward and respect
> the decision of the person making the call.  In this case, whatever
> decision the SKS maintainers make, I will cheerfully accept.

> have arguments in their favor.  Ultimately, it's up to the maintainers
> and the keyserver community to decide which will be the canonical behavior.

I, for one, do want to see this patch/bugfix in SKS as well as
eventually reflected in the pool criteria.

> Although I believe SKS's behavior as it currently stands is technically
> in error, I do not believe the alternatives you are presenting amount to
> a good fix.  I encourage the maintainers and the community to not worry

AIUI, the patch acknowledges that end users won't generally want,
and therefore won't usually request, such extraneous/leaked data.
At the same time, it doesn't fragment the SKS pool unnecessarily.
If that isn't a win-win, I don't know what is.

-- 
Jason Harris           |  PGP:  This _is_ PGP-signed, isn't it?
address@hidden _|_ Got photons? (TM), (C) 2004

pgpVFo3K6jf0O.pgp
Description: PGP signature