[Top] [All Lists]

Re: Protecting fields via message/rfc822 and merging issues

2002-05-16 09:00:12

Chris & Blake:

My comments below, prefixed by [RH]...

To jog your memory, Chris made the original posting.
Blake replied with his comments prefixed with [bcr].

>   The first part of the solution seems like a done deal.  I would note
that we should be able to omit the "orig-date" and "from" fields (required
by RFC 2822) from the inner message if we use the message/partial type vs
message/rfc822 in the protected MIME object.  However, I think it would be
wise if we simply allowed either type in this case.  I think that support
for message/rfc822 is widespread, perhaps almost universal.  However, the
level of support for message/partial is unknown (to me anyway).  Also, use
of message/partial in this way isn't *exactly* for the reasons that RFC2046
describes its use.  Since Ned suggested it, I would guess he thinks it is,

[bcr] One way to think about message/partial is that this header privacy
issue represents a new S/MIME idiom, and thus you need to write a bunch of
code anyway to handle it.  The argument against message/partial would be
that applications are using a separate MIME library which would choke on
message/partial if it didn't already support it, and older clients that are
unaware of this use might fail completely to process the message.  I would
be more in favor of exploring message/rfc822, since I'm fairly certain that
most GUI implementations just pop up a new message window.  This has the
added benefit of automatically providing compartementalization of the
protected headers, since those will be attributes of the new window.

[RH] I think that message/rfc822 should be the mandatory to implement approach. If we want to explore message/partial, it should not be mandatory to implement.

>    b) Discarding the outer 822 message and looking only at the
> inner fields works provided that the inner message is
> complete.  However, it does not work if only a partial
> list of fields is included in the inner message.  Also,
> since we negate the usefulness of the outer message in
> all cases, we strongly encourage that it be a blank
> "dummy" message.  This would effectively require the
> application to do security processing even to display
> the originator, subject line, etc. -- fields normally
> shown in a mailbox view.  Blake also correctly pointed
> out that this would squash useful headers like "trace"
> (i.e., Received:...) and things added by list exploders.

[bcr] Right, and I think this also includes header security policies (not
necessarily cryptography, but generic rewriting) applied by the organization
such as rewritten address lines for host name hiding or adding disclosed
recipients.  I think this is where we start running into a problem, and
where we're in danger of failing.

>   Of these, I think I favor (c).  However, regardless of which option we
choose, we should say something about using dummy values of the "orig-date"
and "from" fields in the event that the originator wants to protect the
confidentiality of that information.  Since these elements are required in
an 822 message, some dummy value MUST be provided in the outer message.  I
don't think we need to necessarily specify what these values should be, but
we should say something about the need for them.

[bcr] I agree -- I think this is going to be part of any work that we

>   Obviously, my belief is that (d) is the only one that works.  However,
I'm not happy with how it works in the encrypted-only case.  I'm also
somewhat sensitive to "attribute bloat".  I therefore earnestly hope
somebody else sees something that I've missed.

[bcr] I think that the biggest problem I'm having is that we're trying to
mix authenticated / unauthenticated / encrypted / unencrypted headers
together and try to do the right thing in an automated fashion.  As much as
as we might like to define this, I think the only option might be to take
the coward's way out and explain that the presentation and merging of the
headers are the problem of the client, and that it's not possible to
automatically mix them.  The realization that I'm coming to is that there is
no utility in merging the headers, and we shouldn't even attempt it, and we
should document that the client needs to potentially make decisions about
how much to trust the internal headers vs. the external headers, and it is
their responsibility to demonstrate the separation.

[bcr] My thinking right now is along the lines of the following, and I could
very well be missing some important issues:

1. Use message/rfc822 with a full set of headers for the inner protected
content.  This is backward compatible, and it's entirely possible that
existing clients might even process this correctly.

2. Define placebo values for any outer message required fields.

3. Explain the client considerations for presentation.

[RH] I would like to see a very simple approach. The sender MUST put the same values in both the 822 header and the inner protected header. Whenever possible, the recipient SHOULD display the values from the inner protected header. We need to explain the cases where this will be difficult and the ones from the outer unprotected header need to be used.