FW: Fwd: Surreptitious Forwarding

Here's some possible text for this that in my opinion is clearer, take it or
leave it:
* * * *
XML Encryption application developers should be 
aware of the possibility of "surreptitious forwarding" 
[Davis] whereby a recipient R of a signed-then-encrypted message incorrectly

infers their status as the *original* recipient of that message, when in
fact R
is merely the recipient of a *forwarded* version of the original
signed message, which the true original recipient has first unencrypted then
reencrypted for delivery to R (without modifying the original signature). 

Then maybe something like this...

To enable the detection of surreptitious forwarding in applications,
application software
may want to guarantee or provide for the inclusion of original recipient
information inside application messages...


Thane Plambeck, Ph.D.
Principal Scientist, Strategic Technology
tplambeck@verisign.com
http://www.verisign.com
650 429 5247 direct, Mt View Office
650 321 4884 home office
650 323 4928 home office fax



-----Original Message-----
From: Don Davis [mailto:dtd@world.std.com]
Sent: Tuesday, July 31, 2001 8:37 PM
To: Joseph M. Reagle Jr.
Cc: XML Encryption WG ; SMathews@conclusive.com
Subject: Re: Fwd: Surreptitious Forwarding


>At 10:54 7/30/2001, Don Davis wrote:
>>      "When an encrypted envelope contains a signature,
>>        the signature does not protect the authenticity
>>        or integrity of the ciphertext, even though the
>>        signature does protect the integrity of the plaintext.
>>        Accordingly, most applications should take care
>>        to prevent the unauthorized replacement of the
>>        encrypted envelope."
>
> I admit I'm beginning to loose traction on these nuances

hi, joseph --

i'm sorry about the nuances, but they do matter, because
your WG wants to make the point with as little text as
possible.  this requires careful phrasing.

> the proposed text in XMLDSIG says what your first
> sentence says (the ciphertext form) *and* don't infer
> authenticity or integrity over "envelope headers."
> If you think that detracts from the warning about
> ciphertext form, I can delete it.

yes, i think so.  please, either make the "don't infer
authenticity" point separately, or omit it.

> I disagree with your second sentence as it brings in
> issues of authorization...

how about:

        Accordingly, most applications should take care
        to detect the unintended replacement of the
        encrypted envelope."

> ... [don's second sentence] violates the principle of the
> warnings: if you want to prevent unauthorized replacement,
> sign it.

i tried to phrase the warning so that it doesn't
stipulate a particular solution.  there are several
possible solutions.  signing the ciphertext is only
one way of preventing replacement, and is the most
expensive way;  the other, simpler way is to include
the recipient's name under the inner signature. this
is harder to specify, but is more likely to get used
in real applications, and it seems that CMS / SMIME
and gnu-pg will fix the problem in this way (with a
signed recipient-list).  instead of referring to
either solution, i think it's best for the docs just
to mention that the problem is real, and to refer
readers to my paper for more info.

here's my modified text, ie, with "not necessarily protect"
and "detect the unintended replacement" in place:

       "When an encrypted envelope contains a signature,
        the signature does not necessarily protect the    <===
        authenticity or integrity of the ciphertext, even
        though the signature does protect the integrity
        of the plaintext.  Accordingly, most applications
        should take care to detect the unintended         <===
        replacement of the encrypted envelope."



						- don





-

Received on Wednesday, 1 August 2001 12:57:45 UTC