ietf-smime
[Top] [All Lists]

comments on the draft, 8bit & binary issues

1997-05-08 08:44:50
The current draft allows the transfer encoding on the secured MIME entities
to be 8bit or binary. We've talked about this before, but I'd like to raise
the issue again because I think it's probably not the right way of doing it
and I'm not sure we've discussed all the points below.

I think it's important to separate the binary discussion from the 8bit
discussion because there reasons for doing one or the other are quite
different. Note also these points are raised for igning and enveloping with
application/pkcs7-mime, not multipart signed. Multipart-signed must be 7bit
as defined by RFC-1847.

Allowing 8bit text mostly avoids the use of quoted-printable/unreadable
which is a big issue outside the US. It forces non-USASCII characters to be
transfer encoded in a way that makes them less readable than just having
the bit stripped (or so I understand).

The disadvantage of allowing 8bit text is that in some cases you can't
remove a layer of security and forward the message on without changing it.
There's no way for the original sender to know what transports the message
might be relayed in at a later time. The only safe assumption is 7bit.

I would suggest that anyone that can unwrap an application/pcks7-mime
message has the ability to transfer decode it. Thus the "quoted-unreadable"
argument doesn't apply.


The big point in favor of allowing binary is that it saves space by
avoiding the layer of base64 on the inside parts in addition to the base64
encoding of the BER encoded PCSK-7 object.

I would argue that a factor against allowing binary MIME is difficulty of
implementation.  I recall in previous discussion that we thought binary was
OK because other transport such as HTTP uses it.  However, nested multipart
objects are not used on the web, and that's when the implementation becomes
more difficult.  It's certainly not impossible, but it will burden many
MIME processors that exist today. There are also mail stores that cannot
store binary MIME in common use today.

Another argument against binary lack of forwardability for unknown
transport as mentioned above in regards to 8bit text.

Last, I think having the same transfer encoding requirements, no matter the
signing or enveloping format is a desirable thing leading to a simpler
standard and simpler implementations and guaranteed forwardability. The
primary cost is the increased size for secured binary objects.

LL



<Prev in Thread] Current Thread [Next in Thread>