[Top] [All Lists]

RE: Protecting fields via message/rfc822 and merging issues

2002-05-23 15:51:44


Some new comments embedded, preceded by [CDB].

Best regards,

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