[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Encrypting RFC822 headers in S/MIME or PGP/MIME messages
> But, I think there is still a question whether this "structural handling"
> information is specific to *just* RFC822. The premise of my suggestion was
> that the structural handling was more widely applicable. I am toying with
> a view that the handling may be appropriate to 'message/...' types in general.
It certainly doesn't apply to the subtypes delivery-status or
disposition-notification. This alone makes calling it a general message type
parameter inappropriate. It would at most be a parameter specific message
subtypes could call on if needed.
It can apply to message/external-body, although it only applies indirectly
when message/external-body references a message/rfc822 object.
Message/partial already has well defined structural considerations (indeed,
these rules should serve as a starting point for defining how to recombine
message/rfc822 objects) and needs no such parameter. I actually would have
suggested using a single part message/partial for this were it not for my
belief that the reassembly rules are likely to be different in some ways.
The type message/news should never have been defined -- message/rfc822 was
designed to accomodate news messages despite its name -- and in practice is not
I don't know about message/http, but I suspect it would need its own rules. And
it isn't clear this issue exists for HTTP anyhow, or that if it does it should
be solved this way.
And that's the entire list of message types.
As a practical matter this sort of structural concern only exists when there's
a set of "outer" headers which are exposed to transport manipulation and hence
cannot be secured by putting them inside of a security enclosure. Now, this
doesn't mean such things cannot appear at an inner level -- this will happen
when someone wants to include an entire message built this way with its
security wrapper intact within another message.
But this does restrict the reasons for using this scheme. We only have two
outer message types which transports manipulate at present: message/rfc822
(which also covers News) and message/http. I don't want to get into
message/http at the present time. And that leaves message/rfc822.
> A recent discusion I had concerned the actual handling differences between
> 'application/...' and 'message/...' (with reference in part to proposing
> 'application/MIME' vs 'message/MIME'). One view was that 'message/...'
> indicates handling that is expected to be performed by a message handling
> agent, where 'application/...' suggests some external program; this seems
> to be consistent with the idea that MIME content-types are used for
> dispatching to a handling module or application.
This is a reasonable view. But it doesn't mean that a message/mime object,
should one be defined, would benefit from this sort of structural handling. If
you want to secure such an object all you have to do is put the whole kit and
kaboodle inside of the security enclosure. I see no justifcation for exposing
part of it outside and having to recombine later. (Yes, I realize that people
have on occasion argued that there's value in confidentiality services that
expose, say, the content-type of of the secured material. However, I remain to
be convinced that this is a good idea, let alone that it should be accomplished
by something similar to this.)
> I feel I may be going over some old ground here, and don't wish to restart
> an old debate, but I would be interested in your view.
See above. Also note that if I'm wrong and there's value in using this
mechanism elsewhere, its definition can easily be borrowed in the definition
of another type or subtype at a later date.