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 Tuesday, 31 July 2001 22:37:30 UTC