Subject: RE: Protecting fields via message/rfc822 and merging issues

From: "Bonatti, Chris" <[email-masked]>
Date: Thu, 23 May 2002 18:51:42 -0400

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.

---

From: "Housley, Russ" <[email-masked]>
Date: Fri, 24 May 2002 09:09:28 -0400

Chris:

See my comment at the end.

>[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.