Bob Jueneman wrote:
I'm curious to know whether anyone tried the test case, either with S/MIME v2
or v3 code.
Any takers?
v2 only (alas ;-) -- the way your message was presented it didn't
parse (via our mime parser anyway) as having an *internal* S/MIME
message, only an attached message and an attached signature (two
vcards, too) -- which we don't try to concatenate and verify -- inside
an outer S/MIME message, which we did (and which verified fine).
I can answer the question about a case where that did occur,
however. We would show the outer message as verifying, as you
suggested it should. The inner message gets its own verification,
which would fail. Not sure if you're familiar with our UI,
but each message gets its own S/MIME icon displayed in the top
far right (across from the message's headers). In the case
of a truly nested inner/outer message, each would have its own
icon with its own statement of validity. In the particular
case you described, the outer message would show "good" and
the attached message would show "bad"; the inner message does
not contaminate the outer -- when the outer message is being
verified the inner stuff is nothing but data getting hashed.
[I have no energy for the discussion about the spoofability
of our UI, so please don't go there. I'd be very happy to
hear practical suggestions for improvements to the UI, however,
if it can convey the same information, similarly succinctly,
and continues to work likewise for attachments which in turn
contain their own signatures. Those were our constraints
going in, along with expecting most users to be unable to
handle any more S/MIME awareness than that a message is "good"
or a message is "bad".]
lisa