Blake:
This e-mail proposes to conclude a short off-list discussion (and
discussion during recent S/MIME WG meeting) by proposing an approach
whereby senders are able to avoid 7-bit transfer encoding inner binary
MIME entities if they know that all intended receivers for the message
are able to process binary entities.
Without this change, unnecessary overheads will be introduced for many
s/mime messages and this is a concern of mail system operators and
persons downloading mail over limited bandwidth channels.
Currently, in [MSG] section 3.1.2 it states that inner MIME entities
SHOULD always be transfer encoded in case intermediate processing
exposes the inner content to non-8-bit clean transport. This is clearly
a safe approach, however in very many common cases where messages are
fully decoded at the "desktop" - or within client/server environments
with 8-bit transport (also common) - it leads to unnecessary message
expansion.
Blake, you have emphasized that there may be problems with some gateways
where inner content may be exposed to non-8-bit safe environments (e.g.
such as DOMSEC in some multipart inner-content situations). Jim Schaad
pointed out at the recent WG meeting that rfc2633 currently requires
support for binary encoding. Also a recent survey of messaging system
implementers indicated that their code could handle binary encoding
(please refer to the WG minutes for further info and where
interoperability concerns are also raised). So clearly we cannot make a
wholesale change; we must retain the ability to accommodate
non-8-bit-safe intermediate environments.
In a previous discussion in 1997 a "preferBinaryInside" sMIMECapability
attribute was suggested, see:
http://www.imc.org/ietf-smime/archive1/msg00249.html
The use of an sMIMECapability OID would provide a means by which
receivers can signal to senders that senders need not 7-bit transfer
encode inner entities. Receivers would only publish this OID if they
are "binary safe".
Since interoperability is not impacted if senders 7-bit transfer encode
anyway, senders should only avoid such transfer encoding if they "know"
(either by receiving this OID or by other means) that the receiver is
binary safe - if the sender does not know, it should 7-bit transfer
encode.
To do this we would need an OID, and a slight change to 2633bis-01:
1. An OID added to http://www.imc.org/ietf-smime/other-smime-oids.asn
For example:
preferBinaryInside OBJECT IDENTIFIER ::=
{sMIMECapabilities xx}
-- (No parameters. In the event that this OID is present,
-- then the receiver is capable of processing binary inner
-- MIME entities and every effort should be made by senders
-- to avoid unnecessary transfer encoding of these entities.
-- Receivers should only publish this capability if they
-- can guarantee that all MIME processing, other than that
-- of the outermost MIME entity, is fully binary capable.)
2. In section 2.5.2, suggest expanding the sentence:
"It also includes a non-algorithm capability which is the preference
for signedData."
To:
"It MAY also be used to indicate additional preferences or capabilities,
for example preference to always receive signed messages or never
receive encrypted messages and the capability to process binary inner
MIME content (see section 3.1.2). Refer to the list of SMIMECapability
OIDs for further information."
3. In section 3.1.2 addition of text something like:
"S/MIME implementations which "know" that all intended recipient(s) are
capable of handling inner (all but the outermost) binary MIME objects
SHOULD NOT use 7-bit transfer encoding for the inner entities since this
would unnecessarily expand the message size. Implementations MAY "know"
that recipient implementations are capable of handling inner binary MIME
entities either by interpreting a corresponding sMIMECapabilities
attribute (see section 2.5.2), by prior agreement, or by other means.
"If one or more intended recipients are unable to handle inner binary
MIME objects, or if this capability in unknown for any of the intended
recipients, S/MIME implementations SHOULD use transfer encoding
described in section 3.1.3 for all MIME entities they secure."
I hope this addresses the issue with minimum fallout!
Regards,
tony