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

vedaal@nym.hush.com Sun, 16 March 2014 03:30 UTC

Return-Path: <vedaal@nym.hush.com>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A33BF1A02BD for <openpgp@ietfa.amsl.com>; Sat, 15 Mar 2014 20:30:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QsyL2grxn8pG for <openpgp@ietfa.amsl.com>; Sat, 15 Mar 2014 20:30:03 -0700 (PDT)
Received: from smtp5.hushmail.com (smtp5.hushmail.com [65.39.178.142]) by ietfa.amsl.com (Postfix) with ESMTP id D60611A0271 for <openpgp@ietf.org>; Sat, 15 Mar 2014 20:29:59 -0700 (PDT)
Received: from smtp5.hushmail.com (localhost [127.0.0.1]) by smtp5.hushmail.com (Postfix) with SMTP id 0CF23601AF for <openpgp@ietf.org>; Sun, 16 Mar 2014 03:29:52 +0000 (UTC)
Received: from smtp.hushmail.com (w5.hushmail.com [65.39.178.80]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp5.hushmail.com (Postfix) with ESMTPS for <openpgp@ietf.org>; Sun, 16 Mar 2014 03:29:51 +0000 (UTC)
Received: by smtp.hushmail.com (Postfix, from userid 99) id E9E462038C; Sun, 16 Mar 2014 03:29:51 +0000 (UTC)
MIME-Version: 1.0
Date: Sat, 15 Mar 2014 23:29:51 -0400
To: openpgp@ietf.org
From: vedaal@nym.hush.com
In-Reply-To: <F4D2857E-0D33-4B6E-8829-9026CE9398DF@callas.org>
References: <80674820640dbeb5ae81f81c67d87541@smtp.hushmail.com> <8761nh1549.fsf@vigenere.g10code.de> <a6d56e791a2c878f34369abc6f09b71d@smtp.hushmail.com> <5323146D.4050006@fifthhorseman.net> <a9cf1a7b7e08e0d601fa5c7c5cf50e71@smtp.hushmail.com> <5323DF28.5070809@fifthhorseman.net> <F4D2857E-0D33-4B6E-8829-9026CE9398DF@callas.org>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20140316032951.E9E462038C@smtp.hushmail.com>
Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/ySvdBdaB9VWiAbG11j4niXJkrz4
Subject: Re: [openpgp] Proposal for a separable ring signature scheme compatible with RSA, DSA, and ECDSA keys
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <openpgp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/openpgp>, <mailto:openpgp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/openpgp/>
List-Post: <mailto:openpgp@ietf.org>
List-Help: <mailto:openpgp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/openpgp>, <mailto:openpgp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 16 Mar 2014 03:30:06 -0000

On 03/15/2014 at 1:47 PM, "Jon Callas" <jon@callas.org> wrote:

>It's really the same problem, just with a one-person variety. It 
>boils down to the fact that revocation doesn't really work, beyond 
>trivial cases.
>
>Now on the other hand, ages ago, we discussed ring signatures, and 
>a use case that I wanted to do was to make it so that whenever 
>Alice sends Bob a signed email or other casual message, she would 
>(could?) sign it with a ring signature of her key and Bob's. Bob 
>knows that he didn't sign it so he knows that Alice did. 


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