Comment # 13 on bug 906589 from grant k

I believe this _may_ be due to our use of GPG release v2.1.0.

We've apparently switched to (now) full/official release for a number of
client-required issues -- two of note are access to the new modular
architecture, and, most importantly (here) ECC support for local and
inter-/intra-company file signing, encryption, etc.

Whether local install is

    (1) src build from gnupg upstream 2.1.0 release tarball
    (2) local rpm build from tumbleweed/factory Base:System's gpg srpm
    (3) rpm install from obs-build of branched tumbleweed/factory Base:System

the issue, is present and consistently mis-behaves as reported above

for GPG 2.1.x use OTHER than zypper, it's been very robust, to date

afaict, there's NO 'official' opensuse pkg'ing of v2.1.0

although there's no indication of a gpg error that I've noticed in the
zypper.log tail I'd attached,

on a test machine, downgrading back to

    rpm -qa | grep -i gpg2
        gpg2-2.0.26-13.1.x86_64
        gpg2-lang-2.0.26-13.1.noarch

in my first few -- not exhaustive -- tests, with the 2.0.x release, when a
repos' contents change, the existing gpg key is NOT re-dl'd.

With 2.1.x, as above, when those contents change, the gpg key IS re-DL'd, after
being recognized as 'unknown'

If this proves to be the cause, with GPG 2.1.0 in full/productuib release,
2.1.1 on its way "real soon now", and ~2.2.2 becoming the new 'stable' GPG @
upstream, ,ight be time to start fussing about this 'officially' ... before it
hits the fan more broadly.

talking @ gpg IRC with devs, tools 'should be' gpg-version agnostic.  it
appears that zypper use isn't completely ... yet.

still poking around ...