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 _______________________________________________ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
