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

Vincent Yu <v@v-yu.com> Fri, 14 March 2014 23:42 UTC

Return-Path: <v@v-yu.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 32B551A0218 for <openpgp@ietfa.amsl.com>; Fri, 14 Mar 2014 16:42:41 -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 TyambD7xDZDA for <openpgp@ietfa.amsl.com>; Fri, 14 Mar 2014 16:42:38 -0700 (PDT)
Received: from smtp10.hushmail.com (smtp10.hushmail.com [65.39.178.143]) by ietfa.amsl.com (Postfix) with ESMTP id 9AADB1A0215 for <openpgp@ietf.org>; Fri, 14 Mar 2014 16:42:38 -0700 (PDT)
Received: from smtp10.hushmail.com (localhost [127.0.0.1]) by smtp10.hushmail.com (Postfix) with SMTP id B3F43C019A for <openpgp@ietf.org>; Fri, 14 Mar 2014 23:42:31 +0000 (UTC)
Received: from smtp.hushmail.com (w9.hushmail.com [65.39.178.29]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp10.hushmail.com (Postfix) with ESMTPS; Fri, 14 Mar 2014 23:42:30 +0000 (UTC)
Message-ID: <a9cf1a7b7e08e0d601fa5c7c5cf50e71@smtp.hushmail.com>
Date: Fri, 14 Mar 2014 19:42:27 -0400
From: Vincent Yu <v@v-yu.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>, Werner Koch <wk@gnupg.org>
References: <80674820640dbeb5ae81f81c67d87541@smtp.hushmail.com> <8761nh1549.fsf@vigenere.g10code.de> <a6d56e791a2c878f34369abc6f09b71d@smtp.hushmail.com> <5323146D.4050006@fifthhorseman.net>
In-Reply-To: <5323146D.4050006@fifthhorseman.net>
X-Enigmail-Version: 1.6
OpenPGP: id=d28d7c4078b3742a; url=https://v-yu.com/pubkeys/openpgp.asc
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="WQecS0gEChleLEDlVdwID72wGK1c9ce8G"
Archived-At: http://mailarchive.ietf.org/arch/msg/openpgp/z3cfWMGNPwIQkPXoWnkiRxm3G18
Cc: openpgp@ietf.org
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: Fri, 14 Mar 2014 23:42:41 -0000

On 03/14/2014 10:38 AM, Daniel Kahn Gillmor wrote:
> On 03/14/2014 09:55 AM, Vincent Yu wrote:
>> I agree with you that it is mostly useless. Unless someone has a better
>> idea, I will remove the registry and modify the new signature subpacket
>> to hold only the fingerprints of possible signers. This will nicely
>> simplify things.
>
> For extra safety, you could still include the public key's algorithm ID
> in the subpacket as a separate one-byte marker, just using the value
> from https://tools.ietf.org/html/rfc4880#section-9.1 instead of pulling
> the values from a new/duplicate registry.

I think I will simply remove the one-byte marker; it just seems like a 
bad idea for me to have added it in the first place. It doesn't seem to 
provide any security or practical benefit, since each public key already 
has a well-defined algorithm associated with it. If the verifier lacks 
one of the public keys, knowing the algorithm ID is not going to help 
them in any way.

> I note that you've specified the ring signature approach as a generic
> public key algorithm for arbitrary signature packets, and left
> "decisions regarding creation and interpretation" up to the
> implementation.  I think a bit more guidance would be helpful in at
> least two cases:
>
> signature types: at the moment, i only see this as a useful mechanism
> for data signatures (sigtype 0x00 and 0x01) ; i don't see a reasonable
> use case here for identity certifications (sigtypes 0x10 through 0x13),
> or other signature types currently available:
> https://tools.ietf.org/html/rfc4880#section-5.2.1  -- i'm not suggesting
> that we need to say these MUST NOT be made as ring signatures, but it
> might be worth considering the applicability to the other signature types.

Yes, it sounds like a good idea to provide a bit more guidance for 
implementers. I agree that signatures of binary documents (0x00) and 
canonical text documents (0x01) are the intended targets of ring 
signatures, and I also don't see reasonable usage scenarios for other 
signature types. Perhaps I should add a short recommendation to fail all 
ring signatures with types other than 0x00 and 0x01. If the implementer 
thinks they have a genuine use for ring signatures with other types, 
they are still free to create them, but they should not expect other 
implementations to verify them.

> Guidance would also be useful for implementations processing (or
> generating) ring signatures that were made by one of a set of keys where
> some of those keys appear to be expired or revoked.  (i haven't thought
> this use case through in sufficient detail, but i could see
> implementations getting tripped up here or behaving in wildly divergent
> ways if there is no clear guidance)

I think a good general recommendation here would be to look at each 
public key individually and output the same warnings and errors that 
would be output if this were a standard signature. Are there significant 
issues that you see with this?

Vincent