RE: encryption in XML & in SMIME

> With S/MIME there is a structural problem that only a part
> of the mail message is actually signed. Not only is there
> possibly important but unsigned information in the To: field,
> but the subject field is also unsigned (and unencrypted).

hi, dr. hallam-baker --

i agree that s/mime could have solved the problem i describe
by requiring that the "To" & "From" lines be signed.  but,
that solution wouldn't help pkcs#7,  which inherits the sign
& encrypt defect from the cms spec.  similarly, signing an
naming header won't apply, when XML application developers
want to use na´ve sign & encrypt to prepare secure XML documents.

though s/mime could have fixed this problem by signing an smtp-
style header (& without resorting to the fixes i've described),
your recharacterization of the problem doesn't help us under-
stand or fix cms/pkcs#7's basic sign/encrypt problem, where no
standard naming header is available.  of course, a pkcs#7
application is free to include a naming header in the body, but
basic out-of-the-box pkcs#7 sign & encrypt is as insecure as
s/mime's sign & encrypt.

> it is a problem with the S/MIME spec rather than the structural
> CMS issue suggested. S/MIME provides good payload security but
> as with PGP the integration to the SMTP message transport is
> lousy.

i'm sorry, but i disagree.  cms (s/mime's & pkcs#7's payload
security) does provide sound signatures, but cms' encryption
doesn't tell the s/mime recipient anything about who has seen
the message, even when the author's signature is present.  in
fact, the message-bodies you cite below as "broken" are perfectly
compliant cms/pkcs#7 documents:

> The problem comes with
>   From:    alice
>   Subject: hello
>   Body:    Encrypt ( Bob, Sign (Alice,  "Body: Hello world"))
> and the different but equally broken
>   From:    alice
>   Subject: hello
>   Body:    Sign ( Alice, Encrypt (Bob,  "Body: Hello world"))

the problem here is that na´ve "sign & encrypt" is not by itself
a strong security primitive, though it is often seen as such.
i'm emphasizing this point here on the XML-Enc list, because
i'm hoping this WG, when it's formed, won't repeat cms' mistake.

btw, thanks for mentioning that s/mime should be encrypting the
subject line for private messages;  i never noticed this defect,
when i analyzed the spec.

					- don davis, boston


Received on Friday, 1 September 2000 03:16:44 UTC