Re: [Sks-devel] 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