Re: [Sks-devel] 0xd5920e937cc1e39b shows signatures with 0xca57ad7c continuing?

[Phil Pennock]

On 2012-06-04 at 11:55 +0200, Gabor Kiss wrote:
> > > Actually it is not true that SKS does not modify certs.
> > 
> > AFAIK, no one in this discussion ever claimed it does.  It was claimed
> 
> I did not say that someone stated this. :-)
> However I say: if one kind of modification is allowed
> then the other is also possible.

Doesn't the set reconciliation algorithm assume that data is only ever
added, and that the views of the data accepted by the two systems will
be identical?

Which is why the recon system has both sides report their set of filters
and aborts if the sets differ: to ensure that the views of the data, and
the data that gets dropped, will match.

I suspect that an expiry filter will need to be added, and a means to
decide how to handle whether that filter blocks interoperation, and how
to reconcile safely.  I think that there are rather more keyservers now
than there were the last time a filter was added (and I still see
reconciliation failures caused by mismatched filters).

If not handled right, this change would partition the mesh into "servers
with the filter" and "servers without the filter" and key updates would
not propagate across the divide.

It's still possible, and expired signature filtering is probably still
worthwhile, but it's going to require a bit of thought and I don't think
it will be as trivial as some are portraying.

Question: if I have a PGP key with an expiry date on the self-sigs, and
signatures from others which extend past the expiry on those self-sigs,
and I resign my key to extend it, but forget to upload it to the
keyservers, and in the meantime others upload signatures which I don't
download, and the key in the keyserver mesh expires and *then* I get the
complaints and re-upload my key, what happens to those other signatures
upon my key?

-Phil