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

Nicholas Cole <nicholas.cole@gmail.com> Sat, 15 March 2014 20:40 UTC

Return-Path: <nicholas.cole@gmail.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 C63E51A020A for <openpgp@ietfa.amsl.com>; Sat, 15 Mar 2014 13:40:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 GxqhErtuviit for <openpgp@ietfa.amsl.com>; Sat, 15 Mar 2014 13:40:35 -0700 (PDT)
Received: from mail-ee0-x22b.google.com (mail-ee0-x22b.google.com [IPv6:2a00:1450:4013:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 5071E1A01B6 for <openpgp@ietf.org>; Sat, 15 Mar 2014 13:40:35 -0700 (PDT)
Received: by mail-ee0-f43.google.com with SMTP id e53so2619645eek.16 for <openpgp@ietf.org>; Sat, 15 Mar 2014 13:40:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=PiUKx0CGST8TjjTK5h5RnQ/mGtTL/+ryG4NPA+Cm6pA=; b=uCtiICuaz70TuxS1F8+93Zd4+gJt31cr5jqadRNYOOrS9NISmWBAvUCeejMp6DsvJd FeRJkdYJlh7A2wFvHEb7lQ4OYR1A1FxACgHwH3sY4dRZNMNhLEMwiSpQxZ/aWAbpxP/x gpfDH2LZlxvLl1G8YA4bp+B97UB7x9SDSQvKCMqS0BKQLfzWyIyLOhF4F8Pa2E6sM5KI 7BSblAkfw8XzJ/1FvGJF/qHgx1R3wb38sLHo/II1T+xxGHuCrbMGfSaZ5Zz03UOM+mGu Km8t2S28lqHUqbSO5nc9jqcoT33ciL8to+XFLQR69K726C9XibhMniaZZVqkQtZc0bWo 7HPA==
MIME-Version: 1.0
X-Received: by 10.14.174.5 with SMTP id w5mr15620688eel.14.1394916027526; Sat, 15 Mar 2014 13:40:27 -0700 (PDT)
Received: by 10.14.80.135 with HTTP; Sat, 15 Mar 2014 13:40:27 -0700 (PDT)
In-Reply-To: <CAAu18hczJb9C2qv-HYJ0kwP7npEgy4f-D0VOMReBSi==XqT9Eg@mail.gmail.com>
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> <CAAu18hczJb9C2qv-HYJ0kwP7npEgy4f-D0VOMReBSi==XqT9Eg@mail.gmail.com>
Date: Sat, 15 Mar 2014 20:40:27 +0000
Message-ID: <CAAu18hc2BPd3u2OnvxMGattGrdEXZgpxTGsR05GU7D-7L10Usw@mail.gmail.com>
From: Nicholas Cole <nicholas.cole@gmail.com>
To: openpgp@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"
Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/x0a3o76J3de0J-46bbw2Dhm_sAo
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: Sat, 15 Mar 2014 20:40:38 -0000

On Sat, Mar 15, 2014 at 8:33 PM, Nicholas Cole <nicholas.cole@gmail.com> wrote:
>
>
> On Saturday, 15 March 2014, Jon Callas <jon@callas.org> wrote:
>>
>> On Mar 14, 2014, at 10:03 PM, Daniel Kahn Gillmor <dkg@fifthhorseman.net>
>> wrote:
>>
>> > i'm just imagining a troubling use case in terms of UI (maybe it isn't
>> > an issue):
>> >
>> > Alice and Bob have keys; Alice decides she wants to frame Bob.  Alice
>> > makes a ring signature with her key and with Bob's key at time T over a
>> > document that is particularly terrible.  She then sets her computer's
>> > clock back to time T-1 and expires or revokes her own key.
>> >
>> > Carol comes along and checks the signature on the terrible document.
>> > her OpenPGP implementation says "this signature was made by either Alice
>> > or Bob, but Alice's key was expired/revoked"
>> >
>> > If Carol is naive, the implication she might take away from such a UI is
>> > that Alice couldn't have made the signature, therefore it must have been
>> > Bob that said the terrible thing.
>> >
>> > I don't know how to clarify the UI to avoid giving that impression.
>>
>> I confess that I don't see it as an issue.
>>
>> There's part of me that wants to say ironically, "Well, I guess we
>> shouldn't do it, then!" But I don't want to be dismissive of your point.
>>
>> But I would also say that a lot of what you're saying is just hard to do
>> -- like revocation. Revocation doesn't work and *can't* work the way one
>> might naively expect it. The situation you describe exists today in a
>> slightly mutated form. Here's an example:
>>
>> Bob is a politician and wants to repudiate a previous position he used to
>> have, so he sets his clock back, revokes his own key and then claims that
>> all the signatures made after that date come from his computer having been
>> hacked back in the day.
>
>
> That is an interesting 'attack' on your own key. Never rely on the date of a
> revocakation signature is obvious when you think about it.  It does make you
> wonder if signature packets like this should have dates at all.  They make
> everything much more complicated in some ways...
>
>
>> 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.
>>
>> Of course, it's one of those things that are cool, and yet it's hard to
>> say what it actually does to improve anything.
>
>
> It also breaks the metaphor of a 'signature' too: the signatures we
> currently have work in a very similar way to the ideal real-world signature.
> This type of signature doesn't: it is a signature only specific people can
> verify, or rather, a signature that could have been made by any one of a
> number of people. The problem might then become proving you were *not* the
> person who made it, rather than the person who did, and proving a negative
> is impossible. I think for that reason I'm not sure would welcome it being
> added to gpg.  "Yes, that is a signature that I could have made, but I
> didn't" is not an easy position...

And thinking about it even further, it compounds a problem that
someone (was it you, Jon?) has written about in the past.  Even though
we all know that key UIDs can be signed by complete strangers, users
are *often* disconcerted by this fact (which is why there is a
no-modifier flag, even if keyservers have never respected it and even
if it would make the use of OpenPGP even more complicated).  Still, a
naive user of an OpenPGP program may draw incorrect inferences about
social relationships from UID signatures.  Imagine the outcry of users
if they discovered that documents were in the wild that 'might' have
been signed by them...

N.