dealing with misplaced signatures

[Kristian Fiskerstrand]

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

What are your reflections around such an addition to SKS? does it make
sense for us to include something like this, or should we leave the
interpretation up to the OpenPGP implementation and keep the keys as
they are in SKS?


[0]
https://bitbucket.org/kristianf/sks-keyserver/changeset/b436e48dd8e08c247b841c5460786655d3e148bf

[1]
http://keys2.kfwebs.net:11371/pks/lookup?op=vindex&search=0xED34CEABE27BAABC

[2]
http://keys2.kfwebs.net:11371/pks/lookup?op=vindex&clean=off&search=0xED34CEABE27BAABC

-- 
----------------------------
Kristian Fiskerstrand
http://www.sumptuouscapital.com
Twitter: @krifisk
----------------------------
Corruptissima re publica plurimæ leges
The greater the degeneration of the republic, the more of its laws
----------------------------
This email was digitally signed using the OpenPGP
standard. If you want to read more about this
The book: Sending Emails - The Safe Way: An
introduction to OpenPGP security is now
available in both Amazon Kindle and Paperback
format at
http://www.amazon.com/dp/B006RSG1S4/
----------------------------
Public PGP key 0xE3EDFAE3 at http://www.sumptuouscapital.com/pgp/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 898 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20120801/ccc110b6/attachment.pgp>