Yes! Again, this is precisely why the extra layer was added (and what I went
to great lengths to try to detail in my original response); the only
difference between what you're doing and what MIME-PEM calls for is the name
of the primary type that's used.
I accidentally substituted application/pem-clear for message/pem-clear.
No problem.
Good -- then I understand how MIME-PEM works but now I've lost
sight, once again, of why changing the CTE may result in an invalid MIC!
It will _not_ result in an invalid MIC if you change the CTE at
message/pem-clear level. An invalid MIC _will_ result if it gets changed at an
inner level.
The CTE on the application/pem-encrypted or message/pem-clear is what gets
changed and that CTE is never subject to the MIC computation.
You can only change this CTE when this whole encapsulation level is there to
change. This whole discussion is about whether or not the message/pem-clear
level is even in there. If it isn't in there an MTA or gateway that's not
PEM-aware will calmly proceed into the interior of the message, muck around,
and thereby mess up the MIC. Having message/pem-clear effectively keeps MTAs
and gateways out of the interior of the privacy enhanced object.
Ned