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

[Jeffrey Johnson]

On Jun 4, 2012, at 3:02 PM, Robert J. Hansen wrote:

> 
> No.  Because if you drop signatures, you are losing information, and
> several people have come out quite adamantly against SKS losing information.
> 

And if signatures start to exceed >1Mb in size, then applications can
break: there are several hints that "buggy" applications might be
related to the size of pubkeys with lots of robo-signatures (although
there is no way to say for sure)

Though one can argue that the application should be able
to handle certificates of *any* size, with >1Mb of deep dark chocolate
pubkey goop, there is the "real world" and diminishing utility
on including "expired" signatures for the historical record when
downloaded repeatedly.

Insisting that SKS key servers *never* undertake some reasonable
policies for sound engineering purposes isn't subject to the number
of adamant objectors, but rather to sensible discussion.

What is being discussed isn't exactly "dropping" signatures, but
rather figuring some way to avoid robotic semi-monthly signatures from
leading to huge pub keys imho.

There are certainly policy enforcement advantages to doing nothing
whatsoever and keeping everything forever.

But that need not be the only or best policy for SKS server forevermore.

73 de Jeff

>> If somebody uploaded a key 10 years ago that had or has expired
>> signatures but he don't touch it key server does not execute any arbitrary
>> changes. It may drop invalid signatures under control of the end user.
> 
> (I'm assuming by "invalid signature" you mean "bad signature.")
> 
> No, it can't.  The only way to determine if a signature is bad is to do
> a cryptographic operation, and SKS has no cryptographic code.
> 
> Expired signatures can still be meaningful, so they must not be dropped.
> 
> _______________________________________________
> Sks-devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/sks-devel