This new type, which is what I was referring to in my earlier messages,
would
explicitly allow for a content-md5 header, and thus both problems would be
resolved.
That seems pretty neat. I'm unclear, however, whether this would take the
form of a
change to PEM/MIME, or to MIME itself. Are you proposing or prepared to add
this
this at this time?
Neither approach is necessary. All that is needed is a brief specification of
the new type. This is then posted to the ietf-types list and, if deemed
acceptable, registered by IANA. It doesn't even have to be an RFC, although in
this case I think it would be good for it to be an RFC.
The specifics of how to use this extension as well as how to use content-md5
fields in the context of security multiparts could either be addressed in this
document or in an update to the content-md5 header specification. It could also
be addressed in the security multiparts document if we wanted to, I guess,
although I'd prefer to get our specification out sooner rather than later.
Do you intend to address the issue of the trusted bind/reference to a remote
object
at the same time? (And again, I'm not sure exactly where the changes would
go.)
There is already language about this in the next (and hopefully final) revision
of the security multiparts document.
Ned