In theory, you're probably correct, but I think this is more of a
hidden assumption than a contradiction. The operative assumption
seems to be that systems dealing with (a) and (b) might all use
CMS, they would not generally need to interoperate. However,
this is not a very strong rationale for omitting the version.
Apart from the MIME design, I would say that the context of
whether the object is (a), (b) or (c) is usually quite clear from
the system context in which it's operating. This kind of
discussion also occurred when we drafted RFCs 3854 and 3855 (CMS
with X.400). On my secure e-mail client, I receive RFC 822
without exception. On my X.400 client, I receive CMS wrapped
X.400 content without exception. In my local file system, the
things I encrypt are files without exception. The context is
clear in all cases, and never do the different cases need to
interoperate directly because they belong to different content
universes. Now if you had some system that might handle RFC 822,
generalized MIME objects, and X.400 content and do something
sensible with each, you might have a problem (though I expect
differentiating these would not be hard anyway). However, I have
never seen such a animal.
This is not so much a reason for omitting the MIME version, as a
explanation for where we are.
If you wanted to introduce this requirement, the trick would be
to do so in a way that does not declare the bulk of S/MIME
products already out there to be broken.
Regards,
Chris
-----Original Message-----
From: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Joachim
Abrahmsén
Sent: Wednesday, June 07, 2006 07:32
To: Ned Freed
Cc: Paul Hoffman; ietf-smime(_at_)imc(_dot_)org
Subject: SV: SV: MIME-Version or not?
Well, I thought the RFC's where designed to handle all cases you
mention, i.e. (a), (b) and (c) below, even if we only use case
(a) for now. We prefer not to make any assumptions about the
contents of the inner object and would like to follow the RFC's
in order to achieve interoperability, even with implementors
outside our group (Swedish energy sector).
When I read section 3.1 of RFC 2311 (S/MIME v2) and RFC 3851
(S/MIME 3.1) I would say that 'MIME-Version' should be included
in both inner and outer MIME-entity as they are unrelated.
Should there be 'MIME-Version' or not in the _inner_ MIME-entity
of an S/MIME enveloped e-mail? Is there a contradiction between
the RFC's, or are we missing something?
Best regards
Joachim Abrahmsén
Thank you for your response,
please note that the question is whether the _inner_
MIME-entity
should
have
MIME-Version included or not.
They argue as follows:
"Here are some arguments why the MIME-version header field
should not
be required in an inner entity of a S/MIME message. I have
chosen to
refer to the most recent RFC versions since these hopefully
address
some of the ambiguities of the preceding versions.
In RFC 2045 (MIME Part One) chapter 3 "MIME Header Fields" the
formal
definition of "entity-headers" does not contain the version
header.
The version header is only part of "MIME-message-headers". And
since
RFC 3851 (S/MIME Version 3.1) concerns securing "MIME entities"
it
seems reasonable to require the "entity-headers" to be included
in the
inner MIME entity
but
not the "MIME-message-headers". Of course the outer S/MIME
message
itself should have a version header. This itself implies (per
definition) that
the
contents (inner entity) is a MIME entity which thereby is
described by
the "entity-headers" Content-Type etc."
I would be very happy to settle, this.
The key question is whether or not the inner object can be (a) a
MIME object, (b) an RFC 822 message, or (c) Something else. If
only (a) is possible then you're dealing with a MIME entity and
the MIME version field is superfluous. If (b) or (c) are possible
then you're supposed to include the field and use it to tell
whether or not you're dealing with a MIME object. (In practice
most agents assume MIME is being used when they see a competent
content-type field, irrespective of MIME-Version. But this isn't
what the specifications call for.)
Ned