W3C home > Mailing lists > Public > xml-encryption@w3.org > August 2000

RE: encryption in XML & in SMIME

From: Dick Brooks <dick@8760.com>
Date: Mon, 28 Aug 2000 10:23:49 -0500
To: "Don Davis" <dtd@world.std.com>, <xml-encryption@w3.org>
Cc: <don@MIT.EDU>, "Ralph R. Swick" <swick@w3.org>, <reagle@w3.org>

Great explanation of the problem. Just wondering, is this problem specific
to the use of detached signatures?

Dick Brooks
Group 8760
110 12th Street North
Birmingham, AL 35203
Fax: 205-250-8057

InsideAgent - Empowering e-commerce solutions

> -----Original Message-----
> From: xml-encryption-request@w3.org
> [mailto:xml-encryption-request@w3.org]On Behalf Of Don Davis
> Sent: Monday, August 28, 2000 10:57 AM
> To: xml-encryption@w3.org
> Cc: don@MIT.EDU; Ralph R. Swick; reagle@w3.org
> Subject: encryption in XML & in SMIME
> this message follows up on discussions i had with ralph swick
> and with joseph reagle, about adding privacy-encryption to
> xml.  both joseph and ralph have suggested that i should
> forward these comments to the new xml-encryption list.
> 					- don davis, boston
> >At 3:06 PM -0400 7/26/00, Ralph R. Swick wrote:
> > ... there is a little-recognized defect in PKCS7,
> > SMIME, and CMS that makes each of them inappropriate
> > for encryption purposes.
> >
> > The issue has to do with signing and encryption on the same
> > text; there is no indication of the intended recipient.  You
> > must put the intended recipients name in the body before you
> > sign but since each of these systems considers the body to
> > be opaque, the clients often forget to embed this additional
> > information.
> >
> > Don's example was of a message signed with public key A
> > and then encrypted with (the intended recipient's) public
> > key B.  The current smime mail implementations, for example,
> > do nothing to prevent the holder of the private key B from
> > re-encrypting the signed message using public key C and
> > forging message headers to make it appear that A intended
> > the message to be viewed by C.
>    the s/mime v3 msg spec (rfc 2633, sec 3.5,
> "signing and encrypting") mentions this difficulty,
> but doesn't acknowledge it as breakage.  the spec
> suggests that either the implementation or the user
> should should decide whether to sign first or to
> encrypt first, according to the security needs of
> the moment.  this suggestion is unrealistic; neither
> software nor end-users are sophisticated enough to
> make the security judgment.  nevertheless, some
> s/mime email clients do offer users a menu choice
> about whether to "sign & encrypt" or to "encrypt
> & sign."
>    this problem was first noted in a 1990 critique
> of x.509 v1.  in a paper i wrote in 1996, i
> discussed this problem as a persitent PKI protocol
> error, and suggested that sign/wrap/sign is the only
> correct solution.  since then, i've decided that it's
> really a naming issue.  whether signing or encryption
> is applied first, s/mime fails to duplicate the
> security meaning of a symmetric-key ciphertext.
> when B receives a symmetric-key ciphertext from A,
> B assumes that:
>    * A sent the message,
>    * no-one else has seen the plaintext,
>    * A intended B to receive the plaintext.
> with s/mime, these assumptions can break down, because
> the recipient may have to rely on the crypto layer to
> _supply_ the target's or the intended recipient's names.
> that is, the problem arises when:
>    * the message plaintexts don't mention the
>      sender's & target's names;
>    * the sender's & target's names are important
>      for understanding the message;
>    * the target _assumes_ that the signer encrypted
>      the message.
> thus, signing and encrypting in either order can
> be vulnerable in some cases:
>    * if the message lacks the intended recipient's
>      name (eg, "John loves you"), and is encrypted
>      before signing, then the recipient B can re-encrypt
>      the message for another recipient's eyes.  this
>      attack misleads the new recipient C to suppose
>      that the author A intended to send to C.  further,
>      the new recipient C will assume that B has not
>      seen the message.
>    * if the message lacks the sender's name (eg,
>      "here's my idea!"), and is signed before
>      encrypting, then any eavesdropper can falsely
>      claim authorship by replacing the sender's
>      signature with the eavesdropper's own signature.
> repair:  if the sender were obliged by the spec to
> name the sender & recipient in his message-body,
> then it wouldn't matter whwther signing or encryption
> were applied first.  with either order, replacing the
> outer layer of crypto would be evident, because the
> outer layer's cert-name wouldn't match the message's
> embedded names.
>    i should emphasize that s/mime, cms, and pkcs#7
> are OK for signing OR encrypting;  it's combining
> the operations that's broken.  OTOH, i'll also
> mention that s/mime & cms stipulate a broken mechanism
> for handling MAC-keys.  i haven't looked at whether
> pkcs#7 offers MACs (symmetric-key message
> authentication codes).
>    the bottom line:  i suggest that these standards are
> not necessarily a good model to emulate, for adding crypto
> to XML.
> 				- don davis, boston
> -
Received on Monday, 28 August 2000 11:27:29 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:31:58 UTC