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

[Vincent Yu <[e-mail]>]

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