The chair speaks....
In the new security aware internet community, it is likely the IESG,
or IAB will accept for standardization a RFC with known security
limitations, without explicitly pointing them out, rating the degree
of danger, and proposing work-arounds where necessary.
As such, RFCXXXX is free to include content-types for "dangerous"
content-types, but must make notes to that effect for each of these
types. An example is ....let's say a interpreted script languge foo
which contains shell escapes. It is reasonable to include this in the
RFCXXXX, but it would be expected to 1) Warn implementors that direct
interpretation of the contents is dangerous and that this script may
"do anything you can", 2) Note that authentication (PEM) and access
control lists may be warrented, for this type and 3) maybe list script
foo specific commands to be filtered for safe operation of this
content-type in random mail. Another class of "dangerous" programs
would be word processor formats, which via macros can read and write
almost anything. No much you can do here but suggest authentication.
This does increase the overhead for defining content-types, but
without it, this document will not likely be acceptable for
standardization. I should also be a required section for any
content-types registered with IANA. Security risks vary from one type
to another.
J. Galvin.... Any helpful words?
Greg V.