Chris:
See my comment at the end.
> > > 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.
>
[CDB] I think that some minor complexity is necessary if the solution is
to apply equally to SignedData and EnvelopedData (which I thought was the
one of the reasons for this approach). Having the same values in the
outer and inner header precludes the latter. Given that you are therefore
going to HAVE to merge inner and outer for some cases, I think that use of
"dummy" values on the outside makes sense if we're only going to have one
way of doing things.
[RH] You are correct. We need to consider the ContentHints attribute
defined in ESS too. The original point of this attribute was to provide a
plaintext subject line. So, we need to provide guidance about the handling
of the plaintext 822 subject line, the ciphertext 822 subject line, and the
ContentHints attribute if all three are present.