RE: encryption in XML & in SMIME

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

These comments are very relevant to systems (namely email) where
there are necessarily both senders and recipients.

However, email is only one possible application of XML and many
of the other applications require only just signer(s)/sender(s) 
or only just decryptor(s)/recipient(s).  In fact, I would rather
avoid using the terms "sender" and "recipient" because they are
too email-centric.  I would rather go with "signer", "verifier",
"encryptor", and "decryptor" when discussing XML Crypto.

Recognizing the applications where XML is intended to be used,
the XML Signature WG has even made the <KeyInfo> element optional
in XML Signatures; which I, and I thing the WG, still think was
the right one.  (<KeyInfo> provides the verification public key,
or at least a hint about it.)  The reason for making <KeyInfo>
optional was to allow applications to handle keys behind the
scenes.

The jist of this is that neither the XML Signature
or XML Encryption specs should mandate that the signer/encryptor or
decryptors/verifiers to be stated.  Instead, I would propose the 
following.

(WARNING: The following suggestion may be regarded as more theoretical
than practical, but please allow me, as an XML zealot, to go off the
deep end once in a while.  I also confess email isn't my expertise.)

To me the problem is not with XML nor XML crypto, but with the fact that
email formats don't use XML.  
So let's look forward to the happy day when email is done in XML:

<EMail>
<To>Captain Kirk</To>
<From>Starfleet Command</From>
<StarDate>2435CE January 19 11:22:33.44 UCT</StarDate>
<Subject>Romulan invasion fleet</Subject>
<Message>Please intercept the Romulan invasion fleet at...</Message>
</EMail>

Here's how the secured message looks whether it was signed then encrypted,
or encrypted then signed.

<Signature>
...
<EMail>
<To>Captain Kirk</To>
<From>Starfleet Command</From>
<StarDate>2435CE January 19 11:22:33.44 UCT</StarDate>
<Subject>Romulan invasion fleet</Subject>
<Message><Encryption>MIIxyz...</Encryption></Message>
</EMail>
...
</Signature>

I've left out a lot of detail.  More detail can be found in
"http://lists.w3.org/Archives/Public/xml-encryption/2000Aug/att-0001/01-xmle
ncoverview.html",
look for the section "How do I use XML Signatures and XML Encryption
together?".

What the above shows is that the Signature can wrap the entire object while
letting only what needs to be encrypted be encrypted.  The <To> and <From>
fields
are signed but still readable by mail apps so there is no mistaking who sent
the mail and who it was intended for no matter what the message text says.

The above is valid whether signing or encrypting was done first.

Ed

P.S.  Another benefit of an XML-based email protocol is that it would allow
the
Subject field to be encrypted.

-----Original Message-----
From: Don Davis [mailto:dtd@world.std.com]
Sent: Monday, August 28, 2000 11: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 14:10:19 UTC