RE: encryption in XML & in SMIME

Don,

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
dick@8760.com
205-250-8053
Fax: 205-250-8057
http://www.8760.com/

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