Ned Freed wrote:
I think application/mime and application/signed that allow binary encoding
inside are a nonstarter. I for one will certainly object to such a
specification getting registered, let alone being placed on the standards
track, and I suspect I will not be alone. [...] Frankly, I think that
this group is doomed to destruction if it pursues this course -- asking the
IESG to charter a group after failing to meet the stated criteria the IESG
said
the group had to meet is one thing -- the IETF is nothing if not flexible --
but then asking to grant that group the authority to pry open one of the most
important application-level standards and change it in ways that will almost
certainly reset it to proposed status boggles my mind.
Application/mime did not come from this group. Application/mime is an
individual submission which went through a 4-week Last Call quite some
time ago and is now in IESG limbo. At the time I sent a formal comment
to the IESG that I believed the document did not adequetely call out the
rather subtle implications of the type and had not been reviewed as
being the modification to the base MIME spec that it was.
The S/MIME specification currently references the application/mime
specification as an external document. I'm pointing out that
referencing this document is technically problematic (not just
politically problematic) and suggesting alternatives.
[...] binary
MIME under encryption (an entirely separate issue, since an encrypted object
isn't purely composite) [...]
Many message security systems have two types of signed objects. There
are transparent signed objects which have the property that the signed
data can be read without knowledge of the particular message security
system, but which are subject to transport mangling and encoding
restrictions. There are also opaque signed objects which are armored
against the transport, but which are unreadable by software not
implementing the particular message security system. multipart/signed
takes care of the "transparent signed" problem only.
The suggested alternatives for the "opaque signed" problem are
applicaiton/mime, application/signed, and signedData inside the pkcs7
object.
Now, I would argue that neither of application/signed nor signedData are
"purely composite", at least no more so than MIME under encryption.
They're both MIME under opaque digital signatures. The only technical
difference between application/signed and signedData is whether the
container parses like MIME or parses like PKCS7, and how difficult it is
for a gateway to convert a multipart/signed into one or other.