Russ,
Some new comments embedded, preceded by [CDB].
Best regards,
Chris
[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.
[CDB] I agree with this suggestion.
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.