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

[Daniel Kahn Gillmor <[e-mail]>]

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.

> A major consideration in the proposed scheme is to make sure that it is
> separable; i.e., that different types of existing keys can be used
> together without a dedicated setup. In the current scheme, signers are
> able to produce a ring signature without any cooperation or setup from
> the other possible signers (as long as they each have an RSA, DSA, or
> ECDSA signing key). I think this is an essential feature; otherwise, it
> would be a pain to make sure that all possible signers have the correct
> type of key.
> 
> Thus, I think it is important to have a new algorithm ID for ring
> signatures so that signers are free to mix together different types of
> keys in the ring signature. I would also prefer to leave RSA and DSA
> keys in the scheme for the same reason.

i still haven't gotten my head around the particular details of the
proposed scheme, but i agree it would be nice for users to be able to
have this feature without requiring their peers to opt into the scheme
by making a new EC key or designating a new usage flag for this purpose.
 Sticking with widespread existing keys and the common "data signing"
usage flag seems like the way to go.

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.

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)

	--dkg