ietf-smime
[Top] [All Lists]

RE: Protecting fields via message/rfc822 and merging issues

2002-05-01 11:14:50

Hi Blake,

  See embedded comments below.

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.

  I don't see this as so big a problem with (c).  All you need to do to make 
sure that you don't override the outer fields is to ensure that recipients 
aren't originating those fields in the inner wrapper.  I could think of a 
number of ways to implement that.  In fact, it sounds like an excellent market 
discriminator.  :-)


d) Include the signal in a CMS attribute - In a signed-only 
or signed-and-encrypted message, the attribute should 
probably be in the inner signedAttrs.  For encrypted-only 
messages, it would have to go in the unprotectedAttrs, 
but this is not optimal since it shares the disadvantages 
of (a).  If this is the way forward, we have to have the 
subsequent discussion of whether to use an existing or 
new attribute.

  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.

  I take the point I think you're making that there might be numerous GOOD ways 
of doing this depending on your assumptions, and that there might therefore not 
be a BEST way.  If a product is capable of showing you both and indicating what 
is authenticated or encrypted and what isn't, that might be best.

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

  I didn't figure we needed to do this, but it's more important in the scenario 
you suggest.  For "Date:" I would suggest 1/1/1970 (zero in UNIX, I think).  I 
guess I don't have a value to suggest for "From:".  The difficulty is that you 
need to have a minimally conformant address.  Anybody out there have a 
suggestion?

3. Explain the client considerations for presentation.

  I still think that we can do better than saying nothing here.  Perhaps we can 
describe a default rule similar to the option (c) I described, hanging under a 
SHOULD.  That way, if there was a good reason to do something different it's 
okay.

Best regards,
Chris




<Prev in Thread] Current Thread [Next in Thread>