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

Vincent Yu <> Fri, 14 March 2014 23:42 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 32B551A0218 for <>; Fri, 14 Mar 2014 16:42:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TyambD7xDZDA for <>; Fri, 14 Mar 2014 16:42:38 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9AADB1A0215 for <>; Fri, 14 Mar 2014 16:42:38 -0700 (PDT)
Received: from (localhost []) by (Postfix) with SMTP id B3F43C019A for <>; Fri, 14 Mar 2014 23:42:31 +0000 (UTC)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS; Fri, 14 Mar 2014 23:42:30 +0000 (UTC)
Message-ID: <>
Date: Fri, 14 Mar 2014 19:42:27 -0400
From: Vincent Yu <>
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 <>, Werner Koch <>
References: <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.6
OpenPGP: id=d28d7c4078b3742a; url=
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="WQecS0gEChleLEDlVdwID72wGK1c9ce8G"
Subject: Re: [openpgp] Proposal for a separable ring signature scheme compatible with RSA, DSA, and ECDSA keys
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 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:
>  -- 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?