There is something fishy with the way zypp handles key changes inside a repo.

Example, GNOME:Next (published at
http://download.opensuse.org/repositories/GNOME:/Next/openSUSE_Factory

while zypper is refreshing the repo, it claims:

Retrieving repository 'GNOME:Next' metadata
-------------------------------------------------------------------------------------------------------[\]
The gpg key signing file 'repomd.xml' will expire in 14 days.
  Repository:       GNOME:Next                                        
  Key Name:         GNOME OBS Project <GNOME@build.opensuse.org>      
  Key Fingerprint:  D3CAF513 5D0A8F97 AB539ED3 65A86F31 629FF0C2      
  Key Created:      Tue 22 Jan 2008 21:46:00 CET                      
  Key Expires:      Fri 23 Sep 2016 23:47:08 CEST (expires in 14 days)
  Rpm Name:         gpg-pubkey-629ff0c2-47965608              

That is 'sort of' correct: this is the old key that WAS in the repo

but even what currently lies in zypp's cache does not match this info:
cat /var/cache/zypp/raw/GNOME:Next/repodata/repomd.xml.key | gpg
pub   dsa1024 2008-01-22 [SC] [expires: 2018-09-27]
      D3CAF5135D0A8F97AB539ED365A86F31629FF0C2
uid           GNOME OBS Project <GNOME@build.opensuse.org>

The KEY ID did not change, but the key validity has been extended

So in fact, everything should be normal and zypp should just accept the new
fact (not changed fingerprints, not changed IDs

It just appears as zypp relies only on the rpm DB in this case which already
contains this key (from an earlier import, as I'm using this repo for a long
time already) 

The whole thing is confusing users and there was a thread on the -factory list
not too long ago about the same effects in a different project (but I could not
find the bug report for it)

All tests done on Tumbleweed
* libzypp-16.2.2-1.1.x86_64
* zypper-1.13.9-1.1.x86_64