Hello,
Jon and David said a similar thing:
I think we should not do this for several reasons, but those reasons
don't matter much: we already have signature notations.
Indeed, that would be the other way of doing it. The likeliness of
implementations actually using it is less if they are not confronted with
the technique though. Is it an idea to add a bit under the notation data
section instead? I'm volunteering.
However, I also think this is a very bad idea. We already have pulled
things out of OpenPGP because they could be used for subliminal
channels,
This is definately the weak point of this strategy, as said in the header.
It applies equally to notation data encoding, of course.
But it it does seem to be the only way to make durable signatures.
Hal liked the idea but pointed out that collisions might have occurred
before the random data was hashed, Actually that is such a strong downer
that I am now wondering what the added value of this approach would be.
But we could specify it to work this way: we'd have a subpacket with
the random data, and its meaning is that this stuff gets hashed first
when we do the signature calculation. We'd be changing the rules for
how signatures are calculated.
I could never agree to such a strong break in compatibility; also
because it would be an optional extension and lead to less complete
implementations breaking on it.
Thanks,
-Rick