dealing with misplaced signatures

[David Shaw]

On Jul 31, 2012, at 6:04 PM, Kristian Fiskerstrand wrote:

> On 2012-07-31 23:29, David Shaw wrote:
> 
>> What's happening here is that the key is mangled on SKS (whether SKS
>> mangled it or it was imported already mangled doesn't matter).  GPG
>> fetches it, and there is some code to move misplaced packets to the
>> right place.  Unfortunately, as you noticed, that code does not work
>> if there is more than one user ID.
>> 
>> This code actually dates to 1998.  The comment: "* Note:  This
>> function does not work if there is more than one user ID."
>> 
> 
> Hi David,
> 
> Any recommendation about how we should handle this scenario within SKS.
> Currently we're having a debate about the existence of signatures not
> 0x18 and 0x28 on the subkey.
> 
> Currently we have a patch[0] ready that allows for these signatures to
> be cleaned in the getting (and vindex) of the key, which at least would
> reduce the problem of re-importing (--recv-key or --refresh) the mangled
> signatures after they have been moved (resulting in duplication). This
> is implemented [1] is in the cleaning layer for vindex and get, and not
> on the data store, so the original data is available at [2] (and
> respective clean=off for get). This approach means that no change is
> necessary to the reconciliation process, and as such maintain backwards
> compatibility.
> 
> However, before creating a Pull Request into the SKS Trunk, we have to
> verify that this solution would not actually violating RFC4880. Although
> there are implications that 0x10-0x13 signatures are for UID/UAT
> packages, and as such would not belong to a subkey, would starting to
> "hide information" be a violation of SKS's neutral way of storing data,
> or is this mitigated by the ability to get the full data using clean=off
> (which iirc is not officially in the HKP specs, or used by any
> implementation).

I don't feel it violates RFC-4880 for SKS to hide incorrect packets.  While SKS can't do a lot of validation as it doesn't have crypto, it certainly can rule out certain packets in certain places without needing the ability to check signatures or the like.

That said, I'm not 100% sure it's a good idea: hiding the packets is potentially harmful.  If GPG could move the bad signature to the right place (and at the moment it cannot do this for a key with more than one user ID), then hiding the packets from GPG prevents this repair from happening.  After all, if GPG doesn't get the packets, it can't move them to the right place.  This means the signatures are effectively lost, which can change the interpretation of a key (a user ID can become not self-signed, and thus invalid, or a revoked user ID could become unrevoked, etc).

So my thought it that while SKS should be free to do this, I think a better solution to the original problem would be to fix GPG to do a better job repairing things.

Possibly a best of both worlds would be to have SKS do its cleaning, and then GPG, after it gained the ability to do a repair, would start requesting keys with "clean=off".  This way, clients that could not repair would not get mangled keys, and clients that could repair would get the whole key and be able to repair it.

David