ietf-openpgp
[Top] [All Lists]

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

2014-03-14 18:42:50
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

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp
<Prev in Thread] Current Thread [Next in Thread>