Re: [openpgp] Proposal for a separable ring signature scheme compatible with RSA, DSA, and ECDSA keys

[Falcon Darkstar Momot <[e-mail]>]

On 3/15/2014 8:29 PM, [e-mail] wrote:
> 
> But isn't it obvious that the key revocation is a scam, when the time of the revocation and the time of its receipt by a key-server, are too far apart?
> (anything more than an hour should be suspicious.)
> 
> The only plausibility Alice may have, is that she couldn't get online soon enough after she revoked her key,
> and this is discoverable if she went online for any other reason.
> 
> If there were some way to make the revocation process not be complete until received and verified by a keyserver,
> and then listed as revoked as of the keyserver's receipt time,
> then it might do away with the 'change the clock and revoke scam' and make revocation more workable.
> 
> 
> vedaal
> 

Even assuming there were protocol support for this (please correct me if
in fact there is), you've also made a great leap in deciding to
effectively trust keyservers as timestamping authorities.

Keep in mind that this would require changes to the keyserver software;
SKS does not have any mechanism I am aware of to make such an assertion.

Bear also in mind when thinking about these two points that the
lamentable policy of refusing to ever purge data (save once) including
key vandalism, fraudulent keys, and similar abuse is traditionally
justified by a lack of time to implement support (or by revocation
persistence which is a separate issue) even for that.

Moreover, most public keyservers are run by volunteers on an at-will
basis, and synchronize with varying speeds.  Virtually anyone may
operate them and there is no standard or process for protecting their
security either individually or as a network.  Shall each of them keep
their own different timestamp for each piece of data?  Or shall they
trust each other's assertions as to timestamping?  Shall new keyservers
trust existing timestamps and is this different from the synchronization
process?

How shall you decide to trust timestamp data, and which copy of it to
trust, with respect to edge cases where a timestamp to be verified falls
within the delta between any two keyservers' receipt of the timestamped
information?  What happens when conflicting timestamps are asserted
between keyservers?

When a timestamp on data from a timestamping keyserver differs from the
timestamp in the signed packet (ie. revocation), what else will be
trusted?  Will the revocation be discarded as fraudulent?  If it is, can
you assume the key is compromised?  If validation succeeds (drift within
the threshold), will the timestamper's timestamp, or the timestamp in
the data be used?

Why is an hour the proper threshold for clock drift?  Is it even
appropriate to specify maximum drift in the standard?

What about keys which are exchanged without a mediating keyserver?  How
will the protocol work when data is not available?  How will existing
data without associated timestamps be treated?  What about offline
verification?

Does any problem arise if that data is arbitrarily timestamped with the
current time as of a keyserver software update?  What happens when
timestamp-less data is received during inter-keyserver synchronization?

There are other questions that need to be answered as well for such a
proposal to work.  However, in the signer-agnostic signatures draft this
surprisingly complex new logic would be pollution (and totally eclipse
the intent of the draft); perhaps you should consider making a proposal
of your own if you can answer those questions well.  The lack of a
useful mechanism for this and other timestamping is indeed a deficiency
and there would be some value in developing an appropriate scheme.

This has of course been discussed before to some extent (at least
https://www.ietf.org/mail-archive/web/openpgp/current/msg07136.html).

--Falcon Darkstar Momot