Tom Zerucha writes:
OK, I don't object as strongly any more. I'm neutral now.
Lets see what the other implementors have to say. If expanding the
definition of an existing packet to "verification (signature or MDC)"
packet is easy to do in the existing code base (incl NAI PGP 6.0!), we can
start implementing this now as a test. Then we would have MDCs and be
able to merge them into the spec, and both spec and code would update in
I think Ian Brown is away from email at present travelling, but
perhaps systemics/Ian Grigg would have comments; the cryptix java PGP
implementation is heavily object oriented -- I would expect that
modifying for MDC sigs would be easy -- just adding a new
specialisation signature, with a new reserved number.
The append hash method however is all new, and has the buffering
problems Tom was identifying, and whilst it is easy to conceptualise
and say "oh that's easy just do blah" actually _doing it_ to some code
brings out the complexity of it fast. PGP's 5.x and 6.x code is
object oriented too.
In short, if you really want to do this, then add an MDC-only signature
type or subtype. The (non)signature packets will be encrypted with the
rest of the stream. In fact, the null cipher type might work as is.
But it's NOT a signature!
I don't know what else to call it because it is identified as the
"signature packet" in the Spec. Maybe we can start calling it the
"frooble" packet if that would be less confusing.
I prefer simply renaming "signature packet" to "verification packet" or
whatever it would be - and this nomenclature change should be done. But I
can't use different words right now with out it being even more confusing.
The name of the packet in RFC2440 doesn't sound like a big stumbling
block here either.