[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Multiple signatures in clearsigned messages (was Re: Cleartext Signatures)



On Wed, Oct 12, 2005 at 12:07:13AM -0700, "Hal Finney" wrote:
> 
> Daniel Nagy writes about multiple cleartext signatures:
> > Some details are missing. For instance, is the order salient? One-pass
> > signantures have to be bracketed, and clearsigned documents are supposed be
> > verifiable in one pass as well. But it does not necessarily imply that the
> > hash algorithms should be listed in reverse signature order in the
> > beginning. Actually, the standard says very little on how to go about it.
> 
> I don't think there is much benefit to putting the hashes in the (reverse)
> order of the signatures.  Rather, you list all of the hashes that will
> be used by any of the signatures, then simultaneously accumulate all
> hash values as you scan the message in one pass.  Now you can verify
> each signature and you would have the hash value at hand.

Actually, the hash value is not enough; you need to carry the whole message
digest object with its internal state. In a system/library where it is not
cloneable, this might be a problem. But I agree that it's no big deal. What
you write above is perfectly consistent with the standard and my planned
implementation. I am not aware of any actual implementation of multiple
cleartext signatures.
 
> I am a bit uncomfortable with the notarization signature in general.
> We have it in the draft but have no experience with it in reality,
> which is kind of the opposite of the usual IETF procedure.  I guess it
> was somebody's bright idea that got stuck in, in case people might want
> to use it someday.
>
> The fact that we may have to add further rules clarifying how to use it
> just emphasizes our lack of experience with the construct.  Often with
> these things you don't find the problems until you actually try to use it
> for something and interoperate with others.  Given that notary signatures
> have been in the draft in some form or other for years without seeing
> any use that I know of, should we consider taking them out?

Please don't. I do have a very good use for them and I'm going to go ahead
with an implementation. As soon as it's working reliably and securely, I
will write up the specifications for inclusion in the standard.

-- 
Daniel