service, and the protected data. I could imagine defining some
multi-security service body part that allows multiple this. That or
changing RFC 1847. I'm not sure this feature is so important that 1847
should be changed for this, but I thought it was worth bringing up.
Well.. it's at Proposed Standard now. It would be kind of hard to make
that big a change in it - unless you could show how it would be 100%
upward-compatible.
Personally, I was surprised that this was so - especially for the 'signed'
variant, where it would have been *very* nice to be able to send out
a plaintext, and several (PGP/MOSS/SMIME/etc) signatures, so all who cared
could verify such signatures as they wished. I must have blinked when this
happened... ;)
Its an unfortunate fact that even the PGP case doesn't mesh quite right with
MOSS, despite using the same MD5 checksum. It seems that PGP tacks some other
junk onto the end of the MD5 checksum, whereas MOSS does not.
I believe it can still be implemented with a single checksum algorithm simply
by cloning the MD5 information at the end and finalizing one copy for MOSS
while saving the other one w/o terminating it for PGP. Ugly but doable.
The tweaks necessary for something like
-multipart/signed
-signed data
-multipart/alternative
-signature1
-signature2
-signature3
are really pretty minor, and I expect that if there's sufficient interest
they could be made without a recycle at proposed. Note also that the semantics
of
-multipart/signed
-multipart/signed
-twice signed data
-signature1
-signature2
are somewhat different, and while this latter construct is legal according to
the present specification, I don't think its a good idea to abuse its semantics
by using it to provide what properly should be signatures in parallel.
Ned