RE: encryption in XML & in SMIME

> So let's say Starfleet Command doesn't want 3rd parties doing this
> kind of thing to its <Message>s.  It would then need to sign the
> <Message> element's contents as well before encrypting.  I take it
> this is the  "sign/wrap/sign" solution mentioned in Don's email.

mr. simon --

yes, that's what i mean by sign/wrap/sign (assuming RSA
key-pairs (a,A) & (b,B)):
                             a  B  a
      Alice --> Bob:  {{{msg}  }  }   .

this supports B's security beliefs:

    * Alice saw and signed the same plaintext as Bob sees;
    * Alice saw and signed the same ciphertext as Bob sees.

thus, Bob can confidently _infer_ that Alice intended
Bob to receive the msg.  (note that this kind of double-
signing is legal in s/mime, because the cms spec explicitly
allows arbitrarily many levels of cryptographic nesting in
message-bodies.)

> Don then says why he feels "sign/wrap/sign" is unsatisfactory in
> S/MIME because the sender and target info isn't signed in S/MIME.
> (Don, am I stating what you said correctly?)

actually, i didn't say that S/W/S is unsatisfactory.
rather, i said that S/W/S isn't necessary in principle:

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

to fix the problem i've described, either S/W/S or named
message-bodies will suffice.  it's too late for s/mime to
stipulate that message-bodies should carry names, so only
S/W/S really works for s/mime.  but, it's not too late for
XML-Encryption to stipulate that encrypted signatures should
carry embedded names, so as to avoid stipulating S/W/S.
the downside of S/W/S is that signing is a slow operation,
so doing it twice is expensive.

> However, in the "sign/wrap/sign" solution I'm suggesting,
> the <To> and <From> elements are signed by the same entity
> that signed the content of the <Message> element before
> encrypting it. That way one can keep <KeyInfo> unsigned
> and still solve the problem.  Right?

yes, if you're willing to make users suffer the performance
hit of having to sign twice.  it would be fine if XML-Enc
were to say: "when encrypting & signing an XML doc't, it's
necessary either:
    * to embed the signer's and decryptor's names,
      or
    * to sign/wrap/sign,
but doing both is not necessary."

					- don davis, boston






-

Received on Monday, 28 August 2000 23:48:14 UTC